* [PATCH v3 2/3] crypto: inside-secure: add SafeXcel EIP197 crypto engine driver
From: Robin Murphy @ 2017-05-03 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424085731.wbg53t5lcler4mng@kwain>
On 24/04/17 09:57, Antoine Tenart wrote:
> Hi Igal,
>
> On Mon, Apr 24, 2017 at 08:50:32AM +0000, Igal Liberman wrote:
>> [...]
>>
>>> + priv->clk = of_clk_get(dev->of_node, 0);
>>> + if (!IS_ERR(priv->clk)) {
>>> + ret = clk_prepare_enable(priv->clk);
>>> + if (ret) {
>>> + dev_err(dev, "unable to enable clk (%d)\n", ret);
>>> + return ret;
>>> + }
>>> + } else {
>>> + /* The clock isn't mandatory */
>>> + if (PTR_ERR(priv->clk) == -EPROBE_DEFER)
>>> + return -EPROBE_DEFER;
>>> + }
>>> +
>>> + ret = dma_set_mask_and_coherent(dev, DMA_BIT_MASK(64));
>>
>> The correct address width of the engine in Marvell SoCs is 40bit.
Is that what the IP block itself is internally limited to, or just how
many bits happen to be wired up externally in the particular Marvell
integrations?
> Oops. I'll update.
If the device itself can handle full 64-bit addresses, then the driver
should reflect that regardless of the integration - describing
integration limitations is the job of the firmware, e.g. with DT
"dma-ranges", assuming they actually matter (typically if the whole SoC
interconnect and physical memory map is the same width then having an
even wider DMA mask doesn't make any difference - 64 bits still just
means "everything").
If it's the case that the IP is configurable and could be synthesised
with various internal address widths, then that might warrant a DT
property to identify the particular configuration if it's not readable
from some ID register, although it may be reasonable in practice to
simply assume the chosen configuration to be sane (i.e. not smaller than
the rest of the system) and that the driver can set the maximal DMA mask
as above.
Robin.
>
> Thanks!
> Antoine
>
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Catalin Marinas @ 2017-05-03 17:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <95597ce9-a46f-1491-ae65-518ed8b8c44c@codeaurora.org>
On Wed, May 03, 2017 at 12:08:21PM -0500, Timur Tabi wrote:
> On 05/03/2017 12:01 PM, Catalin Marinas wrote:
> > On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote:
> >> > Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
> >> > otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
> >> > the get_maintainers includes it.
> > There are other patches that go through arm at kernel.org like
> > arch/arm64/boot/dts/ but the arm-soc guys didn't want a MAINTAINERS
> > entry (I don't remember the reasons).
>
> I'm happy to add additional paths/files, but without a MAINTAINERS entry,
> how would anyone know to CC: that address? I posted 3 versions of my
> defconfig patchset before someone told me that I had to send it to
> arm at kernel.org.
Most of the time it's the arm-soc guys pushing changes to defconfig,
though on occasion the arm64 maintainers make some changes as well.
> Anyway, I really hope it's not too late for my defconfig changes to make
> 4.12. Please consider them. Thank you.
I'm usually fine with such updates immediately after -rc1 but I can't
speak for the arm-soc folk.
--
Catalin
^ permalink raw reply
* [PATCH 1/2] ASoC: sun8i-codec: Add ADC support for a33
From: Chen-Yu Tsai @ 2017-05-03 17:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503135617.25193-2-mylene.josserand@free-electrons.com>
Hi,
On Wed, May 3, 2017 at 9:56 PM, Myl?ne Josserand
<mylene.josserand@free-electrons.com> wrote:
> Add ADC support for the sun8i-codec driver.
>
> This driver uses all the microphones widgets and routes provided by the
> analog part (sun8i-codec-analog).
> Some digital configurations are needed by creating new ADC widgets
> and routes.
>
> Signed-off-by: Myl?ne Josserand <mylene.josserand@free-electrons.com>
> ---
> sound/soc/sunxi/sun8i-codec.c | 80 +++++++++++++++++++++++++++++++++++++++++--
> 1 file changed, 78 insertions(+), 2 deletions(-)
>
> diff --git a/sound/soc/sunxi/sun8i-codec.c b/sound/soc/sunxi/sun8i-codec.c
> index 5723c3404f6b..b4938b06acec 100644
> --- a/sound/soc/sunxi/sun8i-codec.c
> +++ b/sound/soc/sunxi/sun8i-codec.c
> @@ -37,9 +37,11 @@
> #define SUN8I_SYSCLK_CTL_SYSCLK_SRC 0
> #define SUN8I_MOD_CLK_ENA 0x010
> #define SUN8I_MOD_CLK_ENA_AIF1 15
> +#define SUN8I_MOD_CLK_ENA_ADC 3
> #define SUN8I_MOD_CLK_ENA_DAC 2
> #define SUN8I_MOD_RST_CTL 0x014
> #define SUN8I_MOD_RST_CTL_AIF1 15
> +#define SUN8I_MOD_RST_CTL_ADC 3
> #define SUN8I_MOD_RST_CTL_DAC 2
> #define SUN8I_SYS_SR_CTRL 0x018
> #define SUN8I_SYS_SR_CTRL_AIF1_FS 12
> @@ -54,9 +56,25 @@
> #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ 4
> #define SUN8I_AIF1CLK_CTRL_AIF1_WORD_SIZ_16 (1 << 4)
> #define SUN8I_AIF1CLK_CTRL_AIF1_DATA_FMT 2
> +#define SUN8I_AIF1_ADCDAT_CTRL 0x044
> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA 15
> +#define SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA 14
> #define SUN8I_AIF1_DACDAT_CTRL 0x048
> #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0L_ENA 15
> #define SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA 14
> +#define SUN8I_AIF1_MXR_SRC 0x04c
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L 15
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL 14
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL 13
> +#define SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR 12
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R 11
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR 10
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR 9
> +#define SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL 8
> +#define SUN8I_ADC_DIG_CTRL 0x100
> +#define SUN8I_ADC_DIG_CTRL_ENDA 15
The register bit name in the manual is ENAD, as in ENable ADc.
> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DTS 2
> +#define SUN8I_ADC_DIG_CTRL_ADOUT_DLY 1
> #define SUN8I_DAC_DIG_CTRL 0x120
> #define SUN8I_DAC_DIG_CTRL_ENDA 15
> #define SUN8I_DAC_MXR_SRC 0x130
> @@ -276,10 +294,28 @@ static const struct snd_kcontrol_new sun8i_dac_mixer_controls[] = {
> SUN8I_DAC_MXR_SRC_DACR_MXR_SRC_ADCR, 1, 0),
> };
>
> +static const struct snd_kcontrol_new sun8i_input_mixer_controls[] = {
> + SOC_DAPM_DOUBLE("AIF1 Slot 0 Digital ADC Capture Switch",
> + SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF1DA0L,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF1DA0R, 1, 0),
> + SOC_DAPM_DOUBLE("AIF2 Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACL,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACR, 1, 0),
> + SOC_DAPM_DOUBLE("AIF1 Data Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_ADCL,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_ADCR, 1, 0),
> + SOC_DAPM_DOUBLE("AIF2 Inv Digital ADC Capture Switch", SUN8I_AIF1_MXR_SRC,
> + SUN8I_AIF1_MXR_SRC_AD0L_MXL_SRC_AIF2DACR,
> + SUN8I_AIF1_MXR_SRC_AD0R_MXR_SRC_AIF2DACL, 1, 0),
> +};
This group of mixer controls is only for AIF1 slot 0 capture.
So in fact they should all read "AIF1 Slot 0 Mixer X Capture Switch",
with X replaced by "AIF1 Slot 0", "AIF2", "ADC", and "AIF2 Inv".
This hopefully informs the user that these controls are for the AIF1
slot 0 mixer, and are capture switch from the various sources listed
above.
> +
> static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
> - /* Digital parts of the DACs */
> + /* Digital parts of the DACs and ADC */
> SND_SOC_DAPM_SUPPLY("DAC", SUN8I_DAC_DIG_CTRL, SUN8I_DAC_DIG_CTRL_ENDA,
> 0, NULL, 0),
> + SND_SOC_DAPM_SUPPLY("ADC", SUN8I_ADC_DIG_CTRL, SUN8I_ADC_DIG_CTRL_ENDA,
> + 0, NULL, 0),
>
> /* Analog DAC AIF */
> SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left", "Playback", 0,
> @@ -289,17 +325,31 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
> SUN8I_AIF1_DACDAT_CTRL,
> SUN8I_AIF1_DACDAT_CTRL_AIF1_DA0R_ENA, 0),
>
> - /* DAC Mixers */
> + /* Analog ADC AIF */
> + SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Left ADC", "Capture", 0,
> + SUN8I_AIF1_ADCDAT_CTRL,
> + SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0L_ENA, 0),
> + SND_SOC_DAPM_AIF_IN("AIF1 Slot 0 Right ADC", "Capture", 0,
> + SUN8I_AIF1_ADCDAT_CTRL,
> + SUN8I_AIF1_ADCDAT_CTRL_AIF1_DA0R_ENA, 0),
You want to use SND_SOC_DAPM_AIF_OUT here, for captured audio out of
the codec and to the system. These are the last widgets in the capture
path.
> +
> + /* DAC and ADC Mixers */
> SOC_MIXER_ARRAY("Left Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> sun8i_dac_mixer_controls),
> SOC_MIXER_ARRAY("Right Digital DAC Mixer", SND_SOC_NOPM, 0, 0,
> sun8i_dac_mixer_controls),
> + SOC_MIXER_ARRAY("Left Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
> + sun8i_input_mixer_controls),
> + SOC_MIXER_ARRAY("Right Digital ADC Mixer", SND_SOC_NOPM, 0, 0,
> + sun8i_input_mixer_controls),
And these should read "AIF1 Slot 0 Left/Right Mixer".
>
> /* Clocks */
> SND_SOC_DAPM_SUPPLY("MODCLK AFI1", SUN8I_MOD_CLK_ENA,
> SUN8I_MOD_CLK_ENA_AIF1, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("MODCLK DAC", SUN8I_MOD_CLK_ENA,
> SUN8I_MOD_CLK_ENA_DAC, 0, NULL, 0),
> + SND_SOC_DAPM_SUPPLY("MODCLK ADC", SUN8I_MOD_CLK_ENA,
> + SUN8I_MOD_CLK_ENA_ADC, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("AIF1", SUN8I_SYSCLK_CTL,
> SUN8I_SYSCLK_CTL_AIF1CLK_ENA, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("SYSCLK", SUN8I_SYSCLK_CTL,
> @@ -316,6 +366,12 @@ static const struct snd_soc_dapm_widget sun8i_codec_dapm_widgets[] = {
> SUN8I_MOD_RST_CTL_AIF1, 0, NULL, 0),
> SND_SOC_DAPM_SUPPLY("RST DAC", SUN8I_MOD_RST_CTL,
> SUN8I_MOD_RST_CTL_DAC, 0, NULL, 0),
> + SND_SOC_DAPM_SUPPLY("RST ADC", SUN8I_MOD_RST_CTL,
> + SUN8I_MOD_RST_CTL_ADC, 0, NULL, 0),
> +
> + SND_SOC_DAPM_MIC("Headset Mic", NULL),
> + SND_SOC_DAPM_MIC("Mic", NULL),
These Mics are board level widgets. Since you are using simple-card,
you should add them in the device tree in the simple-card device
node, using the "simple-audio-card,widgets" property.
You probably should have done so for the output side as well.
If simple-card were fully-routed, the existing device tree simply
wouldn't work.
> +
> };
>
> static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
> @@ -325,11 +381,16 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
> { "RST AIF1", NULL, "AIF1 PLL" },
> { "MODCLK AFI1", NULL, "RST AIF1" },
> { "DAC", NULL, "MODCLK AFI1" },
> + { "ADC", NULL, "MODCLK AFI1" },
This makes no sense. Why would AIF1's module clock feed the ADC? Same goes
for the existing DAC route.
>
> { "RST DAC", NULL, "SYSCLK" },
> { "MODCLK DAC", NULL, "RST DAC" },
> { "DAC", NULL, "MODCLK DAC" },
>
> + { "RST ADC", NULL, "SYSCLK" },
> + { "MODCLK ADC", NULL, "RST ADC" },
> + { "ADC", NULL, "MODCLK ADC" },
This makes little sense either. The SYSCLK probably feeds the ADC's
module clock.
The MODCLK then feeds the ADC. The ADC reset feeds the ADC (or rather the ADC
depends on its reset). The "ADC" widget here is actually just the enable switch.
But we can use it as a kind of placeholder, to setup the dependencies correctly.
I wish we had named the widgets better, but alas they are part of the
device tree
binding, even though they are not documented, so we can not change the existing
ones.
> +
> /* DAC Routes */
> { "AIF1 Slot 0 Right", NULL, "DAC" },
> { "AIF1 Slot 0 Left", NULL, "DAC" },
> @@ -339,6 +400,12 @@ static const struct snd_soc_dapm_route sun8i_codec_dapm_routes[] = {
> "AIF1 Slot 0 Left"},
> { "Right Digital DAC Mixer", "AIF1 Slot 0 Digital DAC Playback Switch",
> "AIF1 Slot 0 Right"},
> +
> + /* ADC routes */
> + { "Left Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
> + "AIF1 Slot 0 Left ADC" },
> + { "Right Digital ADC Mixer", "AIF1 Data Digital ADC Capture Switch",
> + "AIF1 Slot 0 Right ADC" },
Same thing about the "ADC Mixer" names.
And these routes are completely backwards. "AIF1 Slot 0 Left/Right ADC" are
the output stream widgets. They are fed from "AIF1 Slot 0 Left/Right Mixer"
if you use the names I suggested, or "Left/Right Digital ADC Mixer" originally.
You then need other routes feeding the mixer. Looks like you also need ADC
placeholder widgets on the digital side here, so you can hook up the analog
side in simple-card more easily.
If you can, please dump the DAPM routes into a directed graph to check
everything
is connected and makes sense. I believe you have a script that does this.
Regards
ChenYu
> };
>
> static struct snd_soc_dai_ops sun8i_codec_dai_ops = {
> @@ -356,6 +423,15 @@ static struct snd_soc_dai_driver sun8i_codec_dai = {
> .rates = SNDRV_PCM_RATE_8000_192000,
> .formats = SNDRV_PCM_FMTBIT_S16_LE,
> },
> + /* capture capabilities */
> + .capture = {
> + .stream_name = "Capture",
> + .channels_min = 1,
> + .channels_max = 2,
> + .rates = SNDRV_PCM_RATE_8000_192000,
> + .formats = SNDRV_PCM_FMTBIT_S16_LE,
> + .sig_bits = 24,
> + },
> /* pcm operations */
> .ops = &sun8i_codec_dai_ops,
> };
> --
> 2.11.0
>
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Timur Tabi @ 2017-05-03 17:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503170110.GB23620@e104818-lin.cambridge.arm.com>
On 05/03/2017 12:01 PM, Catalin Marinas wrote:
> On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote:
>> > Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
>> > otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
>> > the get_maintainers includes it.
> There are other patches that go through arm at kernel.org like
> arch/arm64/boot/dts/ but the arm-soc guys didn't want a MAINTAINERS
> entry (I don't remember the reasons).
I'm happy to add additional paths/files, but without a MAINTAINERS entry,
how would anyone know to CC: that address? I posted 3 versions of my
defconfig patchset before someone told me that I had to send it to
arm at kernel.org.
Anyway, I really hope it's not too late for my defconfig changes to make
4.12. Please consider them. Thank you.
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] arm64: Add translation functions for /dev/mem read/write
From: Goel, Sameer @ 2017-05-03 17:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503112639.GG8233@arm.com>
On 5/3/2017 5:26 AM, Will Deacon wrote:
> [adding some /dev/mem fans to cc]
>
> On Tue, May 02, 2017 at 02:28:05PM -0600, Sameer Goel wrote:
>> Port architecture specific xlate and unxlate functions for /dev/mem
>> read/write. This sets up the mapping for a valid physical address if a
>> kernel direct mapping is not already present.
>>
>> This is a generic issue as a user space app should not be allowed to crash
>> the kernel.
>
>> This issue was observed when systemd tried to access performance
>> pointer record from the FPDT table.
>
> Why is it doing that? Is there not a way to get this via /sys?
There is no ACPI FPDT implementation in the kernel, so the userspace systemd code is getting the FPDT table contents from /sys
and parsing the entries. The performance pointer record is a reserved address populated by UEFI and the userspace code tries to
access it using /dev/mem. The physical address is valid, so cannot push back on the user space code.
https://github.com/systemd/systemd/blob/master/src/shared/acpi-fpdt.c
http://www.uefi.org/sites/default/files/resources/ACPI_6.0.pdf 5.2.23
>
>> Ported from commit e045fb2a988a ("x86: PAT avoid aliasing in /dev/mem
>> read/write")
>>
>> Crash Signature:
>> Unable to handle kernel paging request at virtual address ffff800008ff0000
>> pgd = ffff8007de8b2200
>> [ffff800008ff0000] *pgd=0000000000000000, *pud=0000000000000000
>> Internal error: Oops: 96000007 [#1] SMP
>> ................
>> CPU: 0 PID: 1 Comm: systemd Not tainted 4.10.0 #1
>> task: ffff8007c0820000 task.stack: ffff8007c0900000
>> PC is at __arch_copy_to_user+0xb4/0x280
>> LR is at read_mem+0xc0/0x138
>> pc : [<ffff0000084b3bb4>] lr : [<ffff00000869d178>]
>> pstate: 80000145
>> sp : ffff8007c0903d40
>> ....................
>> x3 : ffff800800000000 x2 : 0000000000000008
>> x1 : ffff800008ff0000 x0 : 0000fffff6fdac00
>> ....................
>> Call trace:
>> Exception stack(0xffff8007c0903b70 to 0xffff8007c0903ca0)
>> [<ffff0000084b3bb4>] __arch_copy_to_user+0xb4/0x280
>> [<ffff0000082454d0>] __vfs_read+0x48/0x130
>> [<ffff0000082467dc>] vfs_read+0x8c/0x148
>> [<ffff000008247a34>] SyS_pread64+0x94/0xa8
>> [<ffff0000080833b0>] el0_svc_naked+0x24/0x28
>
> So this certainly looks like a kernel bug, but I don't think your patch is
> the right way to fix it.
I agree that the reserved regions are not meant to be accessed by the kernel as system
ram. So, another option was to to return a NULL for this translation.
Since, the same usage was working on other architectures I ported over the same code to
highlight the issue.
>
>> Code: a88120c7 d503201f d503201f 36180082 (f8408423)
>>
>> Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
>> Tested-by: Shanker Donthineni <shankerd@codeaurora.org>
>> ---
>> arch/arm64/include/asm/io.h | 5 +++++
>> arch/arm64/mm/ioremap.c | 31 +++++++++++++++++++++++++++++++
>> 2 files changed, 36 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/io.h b/arch/arm64/include/asm/io.h
>> index 0c00c87..c869ea4 100644
>> --- a/arch/arm64/include/asm/io.h
>> +++ b/arch/arm64/include/asm/io.h
>> @@ -183,6 +183,11 @@ static inline u64 __raw_readq(const volatile void __iomem *addr)
>> #define iowrite32be(v,p) ({ __iowmb(); __raw_writel((__force __u32)cpu_to_be32(v), p); })
>> #define iowrite64be(v,p) ({ __iowmb(); __raw_writeq((__force __u64)cpu_to_be64(v), p); })
>>
>> +extern void *xlate_dev_mem_ptr(phys_addr_t phys);
>> +extern void unxlate_dev_mem_ptr(phys_addr_t phys, void *addr);
>> +
>> +#define xlate_dev_mem_ptr xlate_dev_mem_ptr
>> +#define unxlate_dev_mem_ptr unxlate_dev_mem_ptr
>> #include <asm-generic/io.h>
>>
>> /*
>> diff --git a/arch/arm64/mm/ioremap.c b/arch/arm64/mm/ioremap.c
>> index c4c8cd4..ba7e63b 100644
>> --- a/arch/arm64/mm/ioremap.c
>> +++ b/arch/arm64/mm/ioremap.c
>> @@ -24,6 +24,7 @@
>> #include <linux/mm.h>
>> #include <linux/vmalloc.h>
>> #include <linux/io.h>
>> +#include <linux/memblock.h>
>>
>> #include <asm/fixmap.h>
>> #include <asm/tlbflush.h>
>> @@ -105,6 +106,36 @@ void __iomem *ioremap_cache(phys_addr_t phys_addr, size_t size)
>> EXPORT_SYMBOL(ioremap_cache);
>>
>> /*
>> + * Convert a physical pointer to a virtual kernel pointer for /dev/mem
>> + * access
>> + */
>> +void *xlate_dev_mem_ptr(phys_addr_t phys)
>> +{
>> + unsigned long start = phys & PAGE_MASK;
>> + unsigned long offset = phys & ~PAGE_MASK;
>> + void *vaddr;
>> +
>> + /* If page is RAM, we can use __va. Otherwise ioremap and unmap. */
>> + if (page_is_ram(start >> PAGE_SHIFT) && memblock_is_memory(phys))
>> + return __va(phys);
>> +
>> + vaddr = ioremap_cache(start, PAGE_SIZE);
>
> Blindly using ioremap like this looks unsafe, since we could accidentally
> set conflict with the attributes of a mapping used by something else (e.g.
> firmware running on another CPU).
>
> I'd like to understand more about the crash, so we can see work out how to
> fix this properly.
>
This does opens up access to any valid physical address. In the short term we
can block this crash by return NULL from this function if the memblock is MEMBLOCK_NOMAP.
Eventually we might need to add another memory type to make sure that it can be mapped.
I have not though about the exact design here.
Thanks,
Sameer
> Will
>
--
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc. Qualcomm Technologies, Inc. is a member of the Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Catalin Marinas @ 2017-05-03 17:01 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493829085-11864-1-git-send-email-timur@codeaurora.org>
On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote:
> Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
> otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
> the get_maintainers includes it.
There are other patches that go through arm at kernel.org like
arch/arm64/boot/dts/ but the arm-soc guys didn't want a MAINTAINERS
entry (I don't remember the reasons).
--
Catalin
^ permalink raw reply
* [PATCH] [v2] MAINTAINERS: arm64 defconfig changes should go to arm@kernel.org
From: Timur Tabi @ 2017-05-03 16:52 UTC (permalink / raw)
To: linux-arm-kernel
Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
the get_maintainers includes it.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
MAINTAINERS | 5 +++++
1 file changed, 5 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 58590cf..5d15858 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2066,6 +2066,11 @@ S: Maintained
F: arch/arm64/
F: Documentation/arm64/
+ARM64 DEFCONFIG
+M: arm at kernel.org
+S: Maintained
+F: arch/arm64/configs/defconfig
+
AS3645A LED FLASH CONTROLLER DRIVER
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-media at vger.kernel.org
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH v5 19/22] KVM: arm64: vgic-its: ITT save and restore
From: Christoffer Dall @ 2017-05-03 16:37 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <8ccb9bec-0df6-732b-c0b3-3c2067c67bf0@redhat.com>
On Wed, May 03, 2017 at 06:08:58PM +0200, Auger Eric wrote:
> Hi Christoffer,
>
> On 30/04/2017 22:14, Christoffer Dall wrote:
> > On Fri, Apr 14, 2017 at 12:15:31PM +0200, Eric Auger wrote:
> >> Introduce routines to save and restore device ITT and their
> >> interrupt table entries (ITE).
> >>
> >> The routines will be called on device table save and
> >> restore. They will become static in subsequent patches.
> >
> > Why this bottom-up approach? Couldn't you start by having the patch
> > that restores the device table and define the static functions that
> > return an error there
> done
> , and then fill them in with subsequent patches
> > (liek this one)?
> >
> > That would have the added benefit of being able to tell how things are
> > designed to be called.
> >
> >>
> >> Signed-off-by: Eric Auger <eric.auger@redhat.com>
> >>
> >> ---
> >> v4 -> v5:
> >> - ITE are now sorted by eventid on the flush
> >> - rename *flush* into *save*
> >> - use macros for shits and masks
> >> - pass ite_esz to vgic_its_save_ite
> >>
> >> v3 -> v4:
> >> - lookup_table and compute_next_eventid_offset become static in this
> >> patch
> >> - remove static along with vgic_its_flush/restore_itt to avoid
> >> compilation warnings
> >> - next field only computed with a shift (mask removed)
> >> - handle the case where the last element has not been found
> >>
> >> v2 -> v3:
> >> - add return 0 in vgic_its_restore_ite (was in subsequent patch)
> >>
> >> v2: creation
> >> ---
> >> virt/kvm/arm/vgic/vgic-its.c | 128 ++++++++++++++++++++++++++++++++++++++++++-
> >> virt/kvm/arm/vgic/vgic.h | 4 ++
> >> 2 files changed, 129 insertions(+), 3 deletions(-)
> >>
> >> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
> >> index 35b2ca1..b02fc3f 100644
> >> --- a/virt/kvm/arm/vgic/vgic-its.c
> >> +++ b/virt/kvm/arm/vgic/vgic-its.c
> >> @@ -23,6 +23,7 @@
> >> #include <linux/interrupt.h>
> >> #include <linux/list.h>
> >> #include <linux/uaccess.h>
> >> +#include <linux/list_sort.h>
> >>
> >> #include <linux/irqchip/arm-gic-v3.h>
> >>
> >> @@ -1695,7 +1696,7 @@ u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
> >> return min_t(u32, next_offset, VITS_DTE_MAX_DEVID_OFFSET);
> >> }
> >>
> >> -u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
> >> +static u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
> >> {
> >> struct list_head *e = &ite->ite_list;
> >> struct its_ite *next;
> >> @@ -1737,8 +1738,8 @@ typedef int (*entry_fn_t)(struct vgic_its *its, u32 id, void *entry,
> >> *
> >> * Return: < 0 on error, 1 if last element identified, 0 otherwise
> >> */
> >> -int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
> >> - int start_id, entry_fn_t fn, void *opaque)
> >> +static int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
> >> + int start_id, entry_fn_t fn, void *opaque)
> >> {
> >> void *entry = kzalloc(esz, GFP_KERNEL);
> >> struct kvm *kvm = its->dev->kvm;
> >> @@ -1773,6 +1774,127 @@ int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
> >> }
> >>
> >> /**
> >> + * vgic_its_save_ite - Save an interrupt translation entry at @gpa
> >> + */
> >> +static int vgic_its_save_ite(struct vgic_its *its, struct its_device *dev,
> >> + struct its_ite *ite, gpa_t gpa, int ite_esz)
> >> +{
> >> + struct kvm *kvm = its->dev->kvm;
> >> + u32 next_offset;
> >> + u64 val;
> >> +
> >> + next_offset = compute_next_eventid_offset(&dev->itt_head, ite);
> >> + val = ((u64)next_offset << KVM_ITS_ITE_NEXT_SHIFT) |
> >> + ((u64)ite->lpi << KVM_ITS_ITE_PINTID_SHIFT) |
> >> + ite->collection->collection_id;
> >> + val = cpu_to_le64(val);
> >> + return kvm_write_guest(kvm, gpa, &val, ite_esz);
> >> +}
> >> +
> >> +/**
> >> + * vgic_its_restore_ite - restore an interrupt translation entry
> >> + * @event_id: id used for indexing
> >> + * @ptr: pointer to the ITE entry
> >> + * @opaque: pointer to the its_device
> >> + * @next: id offset to the next entry
> >> + */
> >> +static int vgic_its_restore_ite(struct vgic_its *its, u32 event_id,
> >> + void *ptr, void *opaque, u32 *next)
> >> +{
> >> + struct its_device *dev = (struct its_device *)opaque;
> >> + struct its_collection *collection;
> >> + struct kvm *kvm = its->dev->kvm;
> >> + u64 val, *p = (u64 *)ptr;
> >
> > nit: initializations on separate line (and possible do that just above
> > assigning val).
> done
> >
> >> + struct vgic_irq *irq;
> >> + u32 coll_id, lpi_id;
> >> + struct its_ite *ite;
> >> + int ret;
> >> +
> >> + val = *p;
> >> + *next = 1;
> >> +
> >> + val = le64_to_cpu(val);
> >> +
> >> + coll_id = val & KVM_ITS_ITE_ICID_MASK;
> >> + lpi_id = (val & KVM_ITS_ITE_PINTID_MASK) >> KVM_ITS_ITE_PINTID_SHIFT;
> >> +
> >> + if (!lpi_id)
> >> + return 0;
> >
> > are all non-zero LPI IDs valid? Don't we have a wrapper that tests if
> > the ID is valid?
> no, lpi_id must be >= GIC_MIN_LPI=8192; added that check.
> ABI Doc says lpi_id==0 is interpreted as invalid. Other values <
> GIC_MIN_LPI cause an -EINVAL error
> >
> > (looks like it's possible to add LPIs with the INTID range of SPIs, SGIs
> > and PPIs here)
>
> >
> >> +
> >> + *next = val >> KVM_ITS_ITE_NEXT_SHIFT;
> >
> > Don't we need to validate this somehow since it will presumably be used
> > to forward a pointer somehow by the caller?
> checked against max number of eventids supported by the device
> >
> >> +
> >> + collection = find_collection(its, coll_id);
> >> + if (!collection)
> >> + return -EINVAL;
> >> +
> >> + ret = vgic_its_alloc_ite(dev, &ite, collection,
> >> + lpi_id, event_id);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + irq = vgic_add_lpi(kvm, lpi_id);
> >> + if (IS_ERR(irq))
> >> + return PTR_ERR(irq);
> >> + ite->irq = irq;
> >> +
> >> + /* restore the configuration of the LPI */
> >> + ret = update_lpi_config(kvm, irq, NULL);
> >> + if (ret)
> >> + return ret;
> >> +
> >> + update_affinity_ite(kvm, ite);
> >> + return 0;
> >> +}
> >> +
> >> +static int vgic_its_ite_cmp(void *priv, struct list_head *a,
> >> + struct list_head *b)
> >> +{
> >> + struct its_ite *itea = container_of(a, struct its_ite, ite_list);
> >> + struct its_ite *iteb = container_of(b, struct its_ite, ite_list);
> >> +
> >> + if (itea->event_id < iteb->event_id)
> >> + return -1;
> >> + else
> >> + return 1;
> >> +}
> >> +
> >> +int vgic_its_save_itt(struct vgic_its *its, struct its_device *device)
> >> +{
> >> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
> >> + gpa_t base = device->itt_addr;
> >> + struct its_ite *ite;
> >> + int ret, ite_esz = abi->ite_esz;
> >
> > nit: initializations on separate line
> OK
> >
> >> +
> >> + list_sort(NULL, &device->itt_head, vgic_its_ite_cmp);
> >> +
> >> + list_for_each_entry(ite, &device->itt_head, ite_list) {
> >> + gpa_t gpa = base + ite->event_id * ite_esz;
> >> +
> >> + ret = vgic_its_save_ite(its, device, ite, gpa, ite_esz);
> >> + if (ret)
> >> + return ret;
> >> + }
> >> + return 0;
> >> +}
> >> +
> >> +int vgic_its_restore_itt(struct vgic_its *its, struct its_device *dev)
> >> +{
> >> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
> >> + gpa_t base = dev->itt_addr;
> >> + int ret, ite_esz = abi->ite_esz;
> >> + size_t max_size = BIT_ULL(dev->nb_eventid_bits) * ite_esz;
> >
> > nit: initializations on separate line
> OK
> >
> >> +
> >> + ret = lookup_table(its, base, max_size, ite_esz, 0,
> >> + vgic_its_restore_ite, dev);
> >
> > nit: extra white space
> >
> >> +
> >> + if (ret < 0)
> >> + return ret;
> >> +
> >> + /* if the last element has not been found we are in trouble */
> >> + return ret ? 0 : -EINVAL;
> >
> > hmm, these are values potentially created by the guest in guest RAM,
> > right? So do we really abort migration and return an error to userspace
> > in this case?
> So we discussed with Peter/dave we shouldn't abort() in qemu in case of
> such error. The restore table IOCTL will return an error. Up to qemu to
> print the error. Destination guest will not be functional though.
>
ok, I'm just wondering if userspace can make a qualified decision based
on this error code. EINVAL typically means that userspace provided
something incorrect, which I suppose in a sense is true, but this should
be the only case where we return EINVAL here. Userspace must be able to
tell the cases apart where the guest programmed bogus into memory before
migration started, in which case we should ignore-and-resume, and where
QEMU errornously provide some bogus value where the machine state
becomes unreliable and must be powered down.
Thanks,
-Christoffer
^ permalink raw reply
* [PATCH v3 1/3] Documentation/bindings: Document the SafeXel cryptographic engine driver
From: Marc Zyngier @ 2017-05-03 16:36 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170424075407.19730-2-antoine.tenart@free-electrons.com>
On 24/04/17 08:54, Antoine Tenart wrote:
> The Inside Secure Safexcel cryptographic engine is found on some Marvell
> SoCs (7k/8k). Document the bindings used by its driver.
>
> Signed-off-by: Antoine Tenart <antoine.tenart@free-electrons.com>
> ---
> .../bindings/crypto/inside-secure-safexcel.txt | 27 ++++++++++++++++++++++
> 1 file changed, 27 insertions(+)
> create mode 100644 Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
>
> diff --git a/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
> new file mode 100644
> index 000000000000..ff56b9384fcc
> --- /dev/null
> +++ b/Documentation/devicetree/bindings/crypto/inside-secure-safexcel.txt
> @@ -0,0 +1,27 @@
> +Inside Secure SafeXcel cryptographic engine
> +
> +Required properties:
> +- compatible: Should be "inside-secure,safexcel-eip197".
> +- reg: Base physical address of the engine and length of memory mapped region.
> +- interrupts: Interrupt numbers for the rings and engine.
> +- interrupt-names: Should be "ring0", "ring1", "ring2", "ring3", "eip", "mem".
> +
> +Optional properties:
> +- clocks: Reference to the crypto engine clock.
> +
> +Example:
> +
> + crypto: crypto at 800000 {
> + compatible = "inside-secure,safexcel-eip197";
> + reg = <0x800000 0x200000>;
> + interrupts = <GIC_SPI 34 (IRQ_TYPE_EDGE_RISING | IRQ_TYPE_LEVEL_HIGH)>,
I'm puzzled. How can the interrupt can be both level *and* edge? That
doesn't make any sense.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Russell King - ARM Linux @ 2017-05-03 16:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493829085-11864-1-git-send-email-timur@codeaurora.org>
On Wed, May 03, 2017 at 11:31:25AM -0500, Timur Tabi wrote:
> Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
> otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
> the get_maintainers includes it.
arm at kernel.org is not a mailing list, it is an alias to those who deal
with those requests.
--
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line: currently at 9.6Mbps down 400kbps up
according to speedtest.net.
^ permalink raw reply
* [PATCH] MAINTAINERS: add arm@kernel.org as the list for arm64 defconfig changes
From: Timur Tabi @ 2017-05-03 16:31 UTC (permalink / raw)
To: linux-arm-kernel
Any changes to arch/arm64/configs/defconfig must be sent to arm at kernel.org,
otherwise they will not get picked up. Add a MAINTAINERS entry to ensure
the get_maintainers includes it.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
MAINTAINERS | 7 +++++++
1 file changed, 7 insertions(+)
diff --git a/MAINTAINERS b/MAINTAINERS
index 58590cf..da2b06b 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2066,6 +2066,13 @@ S: Maintained
F: arch/arm64/
F: Documentation/arm64/
+ARM64 DEFCONFIG
+M: Catalin Marinas <catalin.marinas@arm.com>
+M: Will Deacon <will.deacon@arm.com>
+L: arm at kernel.org
+S: Maintained
+F: arch/arm64/configs/defconfig
+
AS3645A LED FLASH CONTROLLER DRIVER
M: Laurent Pinchart <laurent.pinchart@ideasonboard.com>
L: linux-media at vger.kernel.org
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH] iommu/arm-smmu-v3: Poll for CMDQ drain completion more effectively
From: Sunil Kovvuri @ 2017-05-03 16:24 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503155920.GT8233@arm.com>
On Wed, May 3, 2017 at 9:29 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 03, 2017 at 09:24:13PM +0530, Sunil Kovvuri wrote:
>> On Wed, May 3, 2017 at 9:07 PM, Will Deacon <will.deacon@arm.com> wrote:
>> > On Wed, May 03, 2017 at 06:49:09PM +0530, Sunil Kovvuri wrote:
>> >> On Thu, Apr 27, 2017 at 4:43 PM, <sunil.kovvuri@gmail.com> wrote:
>> >> > From: Sunil Goutham <sgoutham@cavium.com>
>> >> >
>> >> > Modified polling on CMDQ consumer similar to how polling is done for TLB SYNC
>> >> > completion in SMMUv2 driver. Code changes are done with reference to
>> >> >
>> >> > 8513c8930069 iommu/arm-smmu: Poll for TLB sync completion more effectively
>> >> >
>> >> > Poll timeout has been increased which addresses issue of 100us timeout not
>> >> > sufficient, when command queue is full with TLB invalidation commands.
>> >> >
>> >> > Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
>> >> > Signed-off-by: Geetha <gakula@cavium.com>
>> >> > ---
>> >> > drivers/iommu/arm-smmu-v3.c | 15 ++++++++++++---
>> >> > 1 file changed, 12 insertions(+), 3 deletions(-)
>> >> >
>> >> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> >> > index d412bdd..34599d4 100644
>> >> > --- a/drivers/iommu/arm-smmu-v3.c
>> >> > +++ b/drivers/iommu/arm-smmu-v3.c
>> >> > @@ -379,6 +379,9 @@
>> >> > #define CMDQ_SYNC_0_CS_NONE (0UL << CMDQ_SYNC_0_CS_SHIFT)
>> >> > #define CMDQ_SYNC_0_CS_SEV (2UL << CMDQ_SYNC_0_CS_SHIFT)
>> >> >
>> >> > +#define CMDQ_DRAIN_TIMEOUT_US 1000
>> >> > +#define CMDQ_SPIN_COUNT 10
>> >> > +
>> >> > /* Event queue */
>> >> > #define EVTQ_ENT_DWORDS 4
>> >> > #define EVTQ_MAX_SZ_SHIFT 7
>> >> > @@ -737,7 +740,8 @@ static void queue_inc_prod(struct arm_smmu_queue *q)
>> >> > */
>> >> > static int queue_poll_cons(struct arm_smmu_queue *q, bool drain, bool wfe)
>> >> > {
>> >> > - ktime_t timeout = ktime_add_us(ktime_get(), ARM_SMMU_POLL_TIMEOUT_US);
>> >> > + ktime_t timeout = ktime_add_us(ktime_get(), CMDQ_DRAIN_TIMEOUT_US);
>> >> > + unsigned int spin_cnt, delay = 1;
>> >> >
>> >> > while (queue_sync_cons(q), (drain ? !queue_empty(q) : queue_full(q))) {
>> >> > if (ktime_compare(ktime_get(), timeout) > 0)
>> >> > @@ -746,8 +750,13 @@ static int queue_poll_cons(struct arm_smmu_queue *q, bool drain, bool wfe)
>> >> > if (wfe) {
>> >> > wfe();
>> >> > } else {
>> >> > - cpu_relax();
>> >> > - udelay(1);
>> >> > + for (spin_cnt = 0;
>> >> > + spin_cnt < CMDQ_SPIN_COUNT; spin_cnt++) {
>> >> > + cpu_relax();
>> >> > + continue;
>> >> > + }
>> >> > + udelay(delay);
>> >> > + delay *= 2;
>> >> > }
>> >> > }
>> >> >
>> >> > --
>> >> > 2.7.4
>> >> >
>> >>
>> >> Sorry for the ignorance.
>> >> Is there a patchwork where I can check current status of ARM IOMMU
>> >> related patches ?
>> >>
>> >> And is this patch accepted, if not any comments / feedback ?
>> >
>> > Please be patient: the merge window is open and it's not been long since you
>> > posted the patch, which looks pretty bonkers at first glance.
>> >
>> > Will
>>
>> Look at this
>> https://lkml.org/lkml/2017/4/3/605
>> The same thing, i pinged after a week and you said you already picked it up.
>> All I am asking is how do i know the current status, how many days
>> would normally
>> be considered being patient ?
>
> At least wait until the merge window is over if it's not a fix, or keep an
> eye on the relevant branches (see below).
>
>> Instead of troubling you, is there a patchwork where i can check the status ?
>
> No, but I pick patches up on my iommu/devel branch here:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/will/linux.git/
>
> and at some point they appear on for-joerg/arm-smmu/updates, which I send
> to Joerg (who is the iommu maintainer). He then puts them into linux-next
> before they get sent for inclusion in mainline during the next merge window.
>
> Will
Thanks for the info.
Sunil.
^ permalink raw reply
* [PATCH] iommu/arm-smmu-v3: Poll for CMDQ drain completion more effectively
From: Sunil Kovvuri @ 2017-05-03 16:23 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170503154046.GQ8233@arm.com>
On Wed, May 3, 2017 at 9:10 PM, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, May 03, 2017 at 04:33:57PM +0100, Robin Murphy wrote:
>> On 27/04/17 12:13, sunil.kovvuri at gmail.com wrote:
>> > From: Sunil Goutham <sgoutham@cavium.com>
>> >
>> > Modified polling on CMDQ consumer similar to how polling is done for TLB SYNC
>> > completion in SMMUv2 driver. Code changes are done with reference to
>> >
>> > 8513c8930069 iommu/arm-smmu: Poll for TLB sync completion more effectively
>> >
>> > Poll timeout has been increased which addresses issue of 100us timeout not
>> > sufficient, when command queue is full with TLB invalidation commands.
>> >
>> > Signed-off-by: Sunil Goutham <sgoutham@cavium.com>
>> > Signed-off-by: Geetha <gakula@cavium.com>
>> > ---
>> > drivers/iommu/arm-smmu-v3.c | 15 ++++++++++++---
>> > 1 file changed, 12 insertions(+), 3 deletions(-)
>> >
>> > diff --git a/drivers/iommu/arm-smmu-v3.c b/drivers/iommu/arm-smmu-v3.c
>> > index d412bdd..34599d4 100644
>> > --- a/drivers/iommu/arm-smmu-v3.c
>> > +++ b/drivers/iommu/arm-smmu-v3.c
>> > @@ -379,6 +379,9 @@
>> > #define CMDQ_SYNC_0_CS_NONE (0UL << CMDQ_SYNC_0_CS_SHIFT)
>> > #define CMDQ_SYNC_0_CS_SEV (2UL << CMDQ_SYNC_0_CS_SHIFT)
>> >
>> > +#define CMDQ_DRAIN_TIMEOUT_US 1000
>> > +#define CMDQ_SPIN_COUNT 10
>> > +
>> > /* Event queue */
>> > #define EVTQ_ENT_DWORDS 4
>> > #define EVTQ_MAX_SZ_SHIFT 7
>> > @@ -737,7 +740,8 @@ static void queue_inc_prod(struct arm_smmu_queue *q)
>> > */
>> > static int queue_poll_cons(struct arm_smmu_queue *q, bool drain, bool wfe)
>> > {
>> > - ktime_t timeout = ktime_add_us(ktime_get(), ARM_SMMU_POLL_TIMEOUT_US);
>> > + ktime_t timeout = ktime_add_us(ktime_get(), CMDQ_DRAIN_TIMEOUT_US);
>> > + unsigned int spin_cnt, delay = 1;
>> >
>> > while (queue_sync_cons(q), (drain ? !queue_empty(q) : queue_full(q))) {
>> > if (ktime_compare(ktime_get(), timeout) > 0)
>> > @@ -746,8 +750,13 @@ static int queue_poll_cons(struct arm_smmu_queue *q, bool drain, bool wfe)
>> > if (wfe) {
>> > wfe();
>> > } else {
>> > - cpu_relax();
>> > - udelay(1);
>> > + for (spin_cnt = 0;
>> > + spin_cnt < CMDQ_SPIN_COUNT; spin_cnt++) {
>> > + cpu_relax();
>> > + continue;
>> > + }
>> > + udelay(delay);
>> > + delay *= 2;
>>
>> Sorry, I can't make sense of this. The referenced commit uses the spin
>> loop to poll opportunistically a few times before delaying. This loop
>> just adds a short open-coded udelay to an exponential udelay, and it's
>> not really clear that that's any better than a fixed udelay (especially
>> as the two cases in which we poll are somewhat different).
>>
>> What's wrong with simply increasing the timeout value alone?
>
> I asked that the timeout is only increased for the drain case, and that
> we fix the issue here where we udelat if cons didn't move immediately:
>
> http://lists.infradead.org/pipermail/linux-arm-kernel/2017-April/503389.html
>
> but I don't think the patch above actually achieves any of that.
>
> Will
Sorry, I completely screwed up the spin poll above.
Will resubmit.
Thanks,
Sunil.
^ permalink raw reply
* [PATCH 9/9] arm64: defconfig: enable the Qualcomm Technologies EMAC Ethernet driver
From: Timur Tabi @ 2017-05-03 16:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
The EMAC is present on Qualcomm Technologies' server and some mobile
chips, and is used as the primary Ethernet interface.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 424064b..9f574c3 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -191,6 +191,7 @@ CONFIG_IGBVF=y
CONFIG_MVNETA=y
CONFIG_MVPP2=y
CONFIG_SKY2=y
+CONFIG_QCOM_EMAC=m
CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 8/9] arm64: defconfig: enable QCOM_L2_PMU and QCOM_L3_PMU
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
Now that the drivers are available, enable support for L2 and L3
performance monitoring Qualcomm Datacenter Technologies Centriq SoCs.
These PMU drivers provide support for performance optimization.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b8b1374..424064b 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -485,6 +485,8 @@ CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_EMMC=y
CONFIG_PHY_XGENE=y
CONFIG_PHY_TEGRA_XUSB=y
+CONFIG_QCOM_L2_PMU=y
+CONFIG_QCOM_L3_PMU=y
CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_EFI_CAPSULE_LOADER=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 7/9] [v2] arm64: defconfig: enable EDAC options
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
Enable EDAC (Error Detection and Correction) support for ARM64 server
systems that feature it, so that user space applications can be
notified of memory errors.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 389f97f..b8b1374 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -418,6 +418,7 @@ CONFIG_LEDS_SYSCON=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_CPU=y
CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
+CONFIG_EDAC=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MAX77686=y
CONFIG_RTC_DRV_RK808=m
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 6/9] arm64: defconfig: enable APEI and GHES features
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
ARM64 server platforms can support ACPI Platform Error Interface (APEI)
and Generic Hardware Error Source (GHES) features, so enable them.
Platforms which support the firmware-first RAS error reporting model
require APEI and GHES functionality for the OS to receive and report
error records provided by the platform.
PCIe AER functionality is required for PCIe AER errors to be properly
reported and recovered from.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f6b86a1..389f97f 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -488,6 +488,9 @@ CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_ACPI=y
+CONFIG_ACPI_APEI=y
+CONFIG_ACPI_APEI_GHES=y
+CONFIG_ACPI_APEI_PCIEAER=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 5/9] arm64: defconfig: enable support for PCIe hotplug
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
Some ARM64 server systems support PCIe hotplug, so enable the options
for that.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 8099aeb..f6b86a1 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -61,7 +61,10 @@ CONFIG_ARCH_XGENE=y
CONFIG_ARCH_ZX=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_PCI=y
+CONFIG_HOTPLUG_PCI_PCIE=y
CONFIG_PCI_IOV=y
+CONFIG_HOTPLUG_PCI=y
+CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
CONFIG_PCIE_QCOM=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 4/9] [v2] arm64: defconfig: enable EFI_CAPSULE_LOADER
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
CONFIG_EFI_CAPSULE_LOADER allows the user to update the EFI firmware,
which is useful on ARM64 server platforms.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index b2c579d..8099aeb 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -483,6 +483,7 @@ CONFIG_PHY_XGENE=y
CONFIG_PHY_TEGRA_XUSB=y
CONFIG_ARM_SCPI_PROTOCOL=y
CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_EFI_CAPSULE_LOADER=y
CONFIG_ACPI=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 3/9] arm64: defconfig: enable BLK_DEV_NVME
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
NVME is non-volatile storage media attached via PCIe. NVME devices
typically have much higher potential throughput than other block
devices, like SATA, NVME is a must-have requirement for ARM64 based
servers.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index 11f19df..b2c579d 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -153,6 +153,7 @@ CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
+CONFIG_BLK_DEV_NVME=m
CONFIG_SRAM=y
CONFIG_EEPROM_AT25=m
# CONFIG_SCSI_PROC_FS is not set
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 2/9] arm64: defconfig: enable ACPI_CPPC_CPUFREQ
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
The CPPC CPUFreq driver is used on many ACPI-based ARM64 server systems.
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index d916fc3..11f19df 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -89,6 +89,7 @@ CONFIG_CPU_FREQ=y
CONFIG_CPUFREQ_DT=y
CONFIG_ARM_BIG_LITTLE_CPUFREQ=y
CONFIG_ARM_SCPI_CPUFREQ=y
+CONFIG_ACPI_CPPC_CPUFREQ=m
CONFIG_NET=y
CONFIG_PACKET=y
CONFIG_UNIX=y
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 1/9] [v3] arm64: defconfig: resynchronize the defconfig
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1493828280-6620-1-git-send-email-timur@codeaurora.org>
Defconfig files become unsynchronized over time as Kconfig entries are
added, removed, or changed. Making specific changes to the defconfig
becomes difficult as unrelated differences can interfere. This problem
is easily remedied:
make defconfig
make savedefconfig
cp defconfig arch/arm64/configs/defconfig
git add arch/arm64/configs/defconfig
git commit -s <sha>
Signed-off-by: Timur Tabi <timur@codeaurora.org>
---
arch/arm64/configs/defconfig | 103 ++++++++++++++++++-------------------------
1 file changed, 42 insertions(+), 61 deletions(-)
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index ce07285..d916fc3 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -30,7 +30,6 @@ CONFIG_PROFILING=y
CONFIG_JUMP_LABEL=y
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
-# CONFIG_BLK_DEV_BSG is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_ARCH_SUNXI=y
CONFIG_ARCH_ALPINE=y
@@ -62,16 +61,15 @@ CONFIG_ARCH_XGENE=y
CONFIG_ARCH_ZX=y
CONFIG_ARCH_ZYNQMP=y
CONFIG_PCI=y
-CONFIG_PCI_MSI=y
CONFIG_PCI_IOV=y
-CONFIG_PCI_AARDVARK=y
-CONFIG_PCIE_RCAR=y
-CONFIG_PCI_HOST_GENERIC=y
-CONFIG_PCI_XGENE=y
CONFIG_PCI_LAYERSCAPE=y
CONFIG_PCI_HISI=y
CONFIG_PCIE_QCOM=y
CONFIG_PCIE_ARMADA_8K=y
+CONFIG_PCI_AARDVARK=y
+CONFIG_PCIE_RCAR=y
+CONFIG_PCI_HOST_GENERIC=y
+CONFIG_PCI_XGENE=y
CONFIG_ARM64_VA_BITS_48=y
CONFIG_SCHED_MC=y
CONFIG_NUMA=y
@@ -80,12 +78,11 @@ CONFIG_KSM=y
CONFIG_TRANSPARENT_HUGEPAGE=y
CONFIG_CMA=y
CONFIG_SECCOMP=y
-CONFIG_XEN=y
CONFIG_KEXEC=y
CONFIG_CRASH_DUMP=y
+CONFIG_XEN=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_COMPAT=y
-CONFIG_CPU_IDLE=y
CONFIG_HIBERNATION=y
CONFIG_ARM_CPUIDLE=y
CONFIG_CPU_FREQ=y
@@ -155,8 +152,8 @@ CONFIG_MTD_SPI_NOR=y
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_NBD=m
CONFIG_VIRTIO_BLK=y
-CONFIG_EEPROM_AT25=m
CONFIG_SRAM=y
+CONFIG_EEPROM_AT25=m
# CONFIG_SCSI_PROC_FS is not set
CONFIG_BLK_DEV_SD=y
CONFIG_SCSI_SAS_ATA=y
@@ -168,8 +165,8 @@ CONFIG_AHCI_CEVA=y
CONFIG_AHCI_MVEBU=y
CONFIG_AHCI_XGENE=y
CONFIG_AHCI_QORIQ=y
-CONFIG_SATA_RCAR=y
CONFIG_SATA_SIL24=y
+CONFIG_SATA_RCAR=y
CONFIG_PATA_PLATFORM=y
CONFIG_PATA_OF_PLATFORM=y
CONFIG_NETDEVICES=y
@@ -186,18 +183,17 @@ CONFIG_HNS_ENET=y
CONFIG_E1000E=y
CONFIG_IGB=y
CONFIG_IGBVF=y
-CONFIG_MVPP2=y
CONFIG_MVNETA=y
+CONFIG_MVPP2=y
CONFIG_SKY2=y
CONFIG_RAVB=y
CONFIG_SMC91X=y
CONFIG_SMSC911X=y
CONFIG_STMMAC_ETH=m
-CONFIG_REALTEK_PHY=m
+CONFIG_MDIO_BUS_MUX_MMIOREG=y
CONFIG_MESON_GXL_PHY=m
CONFIG_MICREL_PHY=y
-CONFIG_MDIO_BUS_MUX=y
-CONFIG_MDIO_BUS_MUX_MMIOREG=y
+CONFIG_REALTEK_PHY=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_RTL8152=m
@@ -230,14 +226,14 @@ CONFIG_SERIAL_8250_UNIPHIER=y
CONFIG_SERIAL_OF_PLATFORM=y
CONFIG_SERIAL_AMBA_PL011=y
CONFIG_SERIAL_AMBA_PL011_CONSOLE=y
+CONFIG_SERIAL_MESON=y
+CONFIG_SERIAL_MESON_CONSOLE=y
CONFIG_SERIAL_SAMSUNG=y
CONFIG_SERIAL_SAMSUNG_CONSOLE=y
CONFIG_SERIAL_TEGRA=y
CONFIG_SERIAL_SH_SCI=y
CONFIG_SERIAL_SH_SCI_NR_UARTS=11
CONFIG_SERIAL_SH_SCI_CONSOLE=y
-CONFIG_SERIAL_MESON=y
-CONFIG_SERIAL_MESON_CONSOLE=y
CONFIG_SERIAL_MSM=y
CONFIG_SERIAL_MSM_CONSOLE=y
CONFIG_SERIAL_XILINX_PS_UART=y
@@ -261,14 +257,14 @@ CONFIG_I2C_UNIPHIER_F=y
CONFIG_I2C_RCAR=y
CONFIG_I2C_CROS_EC_TUNNEL=y
CONFIG_SPI=y
-CONFIG_SPI_MESON_SPIFC=m
CONFIG_SPI_BCM2835=m
CONFIG_SPI_BCM2835AUX=m
+CONFIG_SPI_MESON_SPIFC=m
CONFIG_SPI_ORION=y
CONFIG_SPI_PL022=y
CONFIG_SPI_QUP=y
-CONFIG_SPI_SPIDEV=m
CONFIG_SPI_S3C64XX=y
+CONFIG_SPI_SPIDEV=m
CONFIG_SPMI=y
CONFIG_PINCTRL_SINGLE=y
CONFIG_PINCTRL_MAX77620=y
@@ -286,39 +282,35 @@ CONFIG_GPIO_PCA953X=y
CONFIG_GPIO_PCA953X_IRQ=y
CONFIG_GPIO_MAX77620=y
CONFIG_POWER_RESET_MSM=y
-CONFIG_BATTERY_BQ27XXX=y
CONFIG_POWER_RESET_XGENE=y
CONFIG_POWER_RESET_SYSCON=y
+CONFIG_BATTERY_BQ27XXX=y
+CONFIG_SENSORS_ARM_SCPI=y
CONFIG_SENSORS_LM90=m
CONFIG_SENSORS_INA2XX=m
-CONFIG_SENSORS_ARM_SCPI=y
-CONFIG_THERMAL=y
-CONFIG_THERMAL_EMULATION=y
CONFIG_THERMAL_GOV_POWER_ALLOCATOR=y
CONFIG_CPU_THERMAL=y
-CONFIG_BCM2835_THERMAL=y
+CONFIG_THERMAL_EMULATION=y
CONFIG_EXYNOS_THERMAL=y
CONFIG_WATCHDOG=y
-CONFIG_BCM2835_WDT=y
-CONFIG_RENESAS_WDT=y
CONFIG_S3C2410_WATCHDOG=y
CONFIG_MESON_GXBB_WATCHDOG=m
CONFIG_MESON_WATCHDOG=m
+CONFIG_RENESAS_WDT=y
+CONFIG_BCM2835_WDT=y
+CONFIG_MFD_CROS_EC=y
+CONFIG_MFD_CROS_EC_I2C=y
CONFIG_MFD_EXYNOS_LPASS=m
+CONFIG_MFD_HI655X_PMIC=y
CONFIG_MFD_MAX77620=y
-CONFIG_MFD_RK808=y
CONFIG_MFD_SPMI_PMIC=y
+CONFIG_MFD_RK808=y
CONFIG_MFD_SEC_CORE=y
-CONFIG_MFD_HI655X_PMIC=y
-CONFIG_REGULATOR=y
-CONFIG_MFD_CROS_EC=y
-CONFIG_MFD_CROS_EC_I2C=y
CONFIG_REGULATOR_FIXED_VOLTAGE=y
CONFIG_REGULATOR_GPIO=y
CONFIG_REGULATOR_HI655X=y
CONFIG_REGULATOR_MAX77620=y
CONFIG_REGULATOR_PWM=y
-CONFIG_REGULATOR_QCOM_SMD_RPM=y
CONFIG_REGULATOR_QCOM_SPMI=y
CONFIG_REGULATOR_RK808=y
CONFIG_REGULATOR_S2MPS11=y
@@ -345,13 +337,12 @@ CONFIG_DRM_EXYNOS_DSI=y
CONFIG_DRM_EXYNOS_HDMI=y
CONFIG_DRM_EXYNOS_MIC=y
CONFIG_DRM_RCAR_DU=m
-CONFIG_DRM_RCAR_HDMI=y
CONFIG_DRM_RCAR_LVDS=y
CONFIG_DRM_RCAR_VSP=y
CONFIG_DRM_TEGRA=m
-CONFIG_DRM_VC4=m
CONFIG_DRM_PANEL_SIMPLE=m
CONFIG_DRM_I2C_ADV7511=m
+CONFIG_DRM_VC4=m
CONFIG_DRM_HISI_KIRIN=m
CONFIG_DRM_MESON=m
CONFIG_FB=y
@@ -366,26 +357,24 @@ CONFIG_SOUND=y
CONFIG_SND=y
CONFIG_SND_SOC=y
CONFIG_SND_BCM2835_SOC_I2S=m
-CONFIG_SND_SOC_RCAR=y
CONFIG_SND_SOC_SAMSUNG=y
+CONFIG_SND_SOC_RCAR=y
CONFIG_SND_SOC_AK4613=y
CONFIG_USB=y
CONFIG_USB_OTG=y
CONFIG_USB_XHCI_HCD=y
-CONFIG_USB_XHCI_PLATFORM=y
-CONFIG_USB_XHCI_RCAR=y
-CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_XHCI_TEGRA=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_EHCI_MSM=y
+CONFIG_USB_EHCI_EXYNOS=y
CONFIG_USB_EHCI_HCD_PLATFORM=y
-CONFIG_USB_OHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD=y
+CONFIG_USB_OHCI_EXYNOS=y
CONFIG_USB_OHCI_HCD_PLATFORM=y
CONFIG_USB_RENESAS_USBHS=m
CONFIG_USB_STORAGE=y
-CONFIG_USB_DWC2=y
CONFIG_USB_DWC3=y
+CONFIG_USB_DWC2=y
CONFIG_USB_CHIPIDEA=y
CONFIG_USB_CHIPIDEA_UDC=y
CONFIG_USB_CHIPIDEA_HOST=y
@@ -398,7 +387,6 @@ CONFIG_USB_RENESAS_USBHS_UDC=m
CONFIG_MMC=y
CONFIG_MMC_BLOCK_MINORS=32
CONFIG_MMC_ARMMMCI=y
-CONFIG_MMC_MESON_GX=y
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_ACPI=y
CONFIG_MMC_SDHCI_PLTFM=y
@@ -406,6 +394,7 @@ CONFIG_MMC_SDHCI_OF_ARASAN=y
CONFIG_MMC_SDHCI_OF_ESDHC=y
CONFIG_MMC_SDHCI_CADENCE=y
CONFIG_MMC_SDHCI_TEGRA=y
+CONFIG_MMC_MESON_GX=y
CONFIG_MMC_SDHCI_MSM=y
CONFIG_MMC_SPI=y
CONFIG_MMC_SDHI=y
@@ -414,32 +403,31 @@ CONFIG_MMC_DW_EXYNOS=y
CONFIG_MMC_DW_K3=y
CONFIG_MMC_DW_ROCKCHIP=y
CONFIG_MMC_SUNXI=y
-CONFIG_MMC_SDHCI_XENON=y
CONFIG_MMC_BCM2835=y
+CONFIG_MMC_SDHCI_XENON=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y
CONFIG_LEDS_GPIO=y
CONFIG_LEDS_PWM=y
CONFIG_LEDS_SYSCON=y
-CONFIG_LEDS_TRIGGERS=y
-CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_LEDS_TRIGGER_HEARTBEAT=y
CONFIG_LEDS_TRIGGER_CPU=y
+CONFIG_LEDS_TRIGGER_DEFAULT_ON=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_DRV_MAX77686=y
+CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_S5M=y
CONFIG_RTC_DRV_DS3232=y
CONFIG_RTC_DRV_EFI=y
+CONFIG_RTC_DRV_S3C=y
CONFIG_RTC_DRV_PL031=y
CONFIG_RTC_DRV_SUN6I=y
-CONFIG_RTC_DRV_RK808=m
CONFIG_RTC_DRV_TEGRA=y
CONFIG_RTC_DRV_XGENE=y
-CONFIG_RTC_DRV_S3C=y
CONFIG_DMADEVICES=y
+CONFIG_DMA_BCM2835=m
CONFIG_MV_XOR_V2=y
CONFIG_PL330_DMA=y
-CONFIG_DMA_BCM2835=m
CONFIG_TEGRA20_APB_DMA=y
CONFIG_QCOM_BAM_DMA=y
CONFIG_QCOM_HIDMA_MGMT=y
@@ -452,18 +440,17 @@ CONFIG_VIRTIO_BALLOON=y
CONFIG_VIRTIO_MMIO=y
CONFIG_XEN_GNTDEV=y
CONFIG_XEN_GRANT_DEV_ALLOC=y
+CONFIG_COMMON_CLK_RK808=y
CONFIG_COMMON_CLK_SCPI=y
CONFIG_COMMON_CLK_CS2000_CP=y
CONFIG_COMMON_CLK_S2MPS11=y
-CONFIG_COMMON_CLK_PWM=y
-CONFIG_COMMON_CLK_RK808=y
CONFIG_CLK_QORIQ=y
+CONFIG_COMMON_CLK_PWM=y
CONFIG_COMMON_CLK_QCOM=y
CONFIG_MSM_GCC_8916=y
CONFIG_MSM_GCC_8994=y
CONFIG_MSM_MMCC_8996=y
CONFIG_HWSPINLOCK_QCOM=y
-CONFIG_MAILBOX=y
CONFIG_ARM_MHU=y
CONFIG_PLATFORM_MHU=y
CONFIG_BCM2835_MBOX=y
@@ -472,32 +459,29 @@ CONFIG_ARM_SMMU=y
CONFIG_ARM_SMMU_V3=y
CONFIG_RASPBERRYPI_POWER=y
CONFIG_QCOM_SMEM=y
-CONFIG_QCOM_SMD=y
-CONFIG_QCOM_SMD_RPM=y
CONFIG_ROCKCHIP_PM_DOMAINS=y
CONFIG_ARCH_TEGRA_132_SOC=y
CONFIG_ARCH_TEGRA_210_SOC=y
CONFIG_ARCH_TEGRA_186_SOC=y
CONFIG_EXTCON_USB_GPIO=y
+CONFIG_IIO=y
+CONFIG_EXYNOS_ADC=y
CONFIG_PWM=y
CONFIG_PWM_BCM2835=m
+CONFIG_PWM_MESON=m
CONFIG_PWM_ROCKCHIP=y
+CONFIG_PWM_SAMSUNG=y
CONFIG_PWM_TEGRA=m
-CONFIG_PWM_MESON=m
-CONFIG_COMMON_RESET_HI6220=y
CONFIG_PHY_RCAR_GEN3_USB2=y
CONFIG_PHY_HI6220_USB=y
+CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_ROCKCHIP_INNO_USB2=y
CONFIG_PHY_ROCKCHIP_EMMC=y
-CONFIG_PHY_SUN4I_USB=y
CONFIG_PHY_XGENE=y
CONFIG_PHY_TEGRA_XUSB=y
CONFIG_ARM_SCPI_PROTOCOL=y
-CONFIG_ACPI=y
-CONFIG_IIO=y
-CONFIG_EXYNOS_ADC=y
-CONFIG_PWM_SAMSUNG=y
CONFIG_RASPBERRYPI_FIRMWARE=y
+CONFIG_ACPI=y
CONFIG_EXT2_FS=y
CONFIG_EXT3_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
@@ -511,7 +495,6 @@ CONFIG_FUSE_FS=m
CONFIG_CUSE=m
CONFIG_OVERLAY_FS=m
CONFIG_VFAT_FS=y
-CONFIG_TMPFS=y
CONFIG_HUGETLBFS=y
CONFIG_CONFIGFS_FS=y
CONFIG_EFIVAR_FS=y
@@ -539,11 +522,9 @@ CONFIG_MEMTEST=y
CONFIG_SECURITY=y
CONFIG_CRYPTO_ECHAINIV=y
CONFIG_CRYPTO_ANSI_CPRNG=y
-CONFIG_CRYPTO_DEV_SAFEXCEL=m
CONFIG_ARM64_CRYPTO=y
CONFIG_CRYPTO_SHA1_ARM64_CE=y
CONFIG_CRYPTO_SHA2_ARM64_CE=y
CONFIG_CRYPTO_GHASH_ARM64_CE=y
CONFIG_CRYPTO_AES_ARM64_CE_CCM=y
CONFIG_CRYPTO_AES_ARM64_CE_BLK=y
-# CONFIG_CRYPTO_AES_ARM64_NEON_BLK is not set
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply related
* [PATCH 0/9] [v3] [RESEND] arm64: defconfig: enable several options useful for ARM64 server platforms
From: Timur Tabi @ 2017-05-03 16:17 UTC (permalink / raw)
To: linux-arm-kernel
ACPI-based ARM64 server platforms based, like the Qualcomm Datacenter
Technologies QDF2400, need several features and drivers enabled for
full functionality. This patchset enables many of those features.
The first patch, "resynchronize the defconfig" refreshes the ARM64
defconfig so that it's aligned with savedefconfig. This needs to be
done periodically, so that new patches avoid merge conflicts.
If the first patch does not apply cleanly, I ask the maintainer to
refresh it himself manually, following the instructions in the commit
message. The remaining 8 patches should apply cleanly on top of that.
Timur Tabi (9):
[v3] arm64: defconfig: resynchronize the defconfig
arm64: defconfig: enable ACPI_CPPC_CPUFREQ
arm64: defconfig: enable BLK_DEV_NVME
[v2] arm64: defconfig: enable EFI_CAPSULE_LOADER
arm64: defconfig: enable support for PCIe hotplug
arm64: defconfig: enable APEI and GHES features
[v2] arm64: defconfig: enable EDAC options
arm64: defconfig: enable QCOM_L2_PMU and QCOM_L3_PMU
arm64: defconfig: enable the Qualcomm Technologies EMAC Ethernet
driver
arch/arm64/configs/defconfig | 116 ++++++++++++++++++++-----------------------
1 file changed, 55 insertions(+), 61 deletions(-)
--
Qualcomm Datacenter Technologies, Inc. as an affiliate of Qualcomm
Technologies, Inc. Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.
^ permalink raw reply
* [PATCH v5 19/22] KVM: arm64: vgic-its: ITT save and restore
From: Auger Eric @ 2017-05-03 16:08 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170430201438.GB1499@lvm>
Hi Christoffer,
On 30/04/2017 22:14, Christoffer Dall wrote:
> On Fri, Apr 14, 2017 at 12:15:31PM +0200, Eric Auger wrote:
>> Introduce routines to save and restore device ITT and their
>> interrupt table entries (ITE).
>>
>> The routines will be called on device table save and
>> restore. They will become static in subsequent patches.
>
> Why this bottom-up approach? Couldn't you start by having the patch
> that restores the device table and define the static functions that
> return an error there
done
, and then fill them in with subsequent patches
> (liek this one)?
>
> That would have the added benefit of being able to tell how things are
> designed to be called.
>
>>
>> Signed-off-by: Eric Auger <eric.auger@redhat.com>
>>
>> ---
>> v4 -> v5:
>> - ITE are now sorted by eventid on the flush
>> - rename *flush* into *save*
>> - use macros for shits and masks
>> - pass ite_esz to vgic_its_save_ite
>>
>> v3 -> v4:
>> - lookup_table and compute_next_eventid_offset become static in this
>> patch
>> - remove static along with vgic_its_flush/restore_itt to avoid
>> compilation warnings
>> - next field only computed with a shift (mask removed)
>> - handle the case where the last element has not been found
>>
>> v2 -> v3:
>> - add return 0 in vgic_its_restore_ite (was in subsequent patch)
>>
>> v2: creation
>> ---
>> virt/kvm/arm/vgic/vgic-its.c | 128 ++++++++++++++++++++++++++++++++++++++++++-
>> virt/kvm/arm/vgic/vgic.h | 4 ++
>> 2 files changed, 129 insertions(+), 3 deletions(-)
>>
>> diff --git a/virt/kvm/arm/vgic/vgic-its.c b/virt/kvm/arm/vgic/vgic-its.c
>> index 35b2ca1..b02fc3f 100644
>> --- a/virt/kvm/arm/vgic/vgic-its.c
>> +++ b/virt/kvm/arm/vgic/vgic-its.c
>> @@ -23,6 +23,7 @@
>> #include <linux/interrupt.h>
>> #include <linux/list.h>
>> #include <linux/uaccess.h>
>> +#include <linux/list_sort.h>
>>
>> #include <linux/irqchip/arm-gic-v3.h>
>>
>> @@ -1695,7 +1696,7 @@ u32 compute_next_devid_offset(struct list_head *h, struct its_device *dev)
>> return min_t(u32, next_offset, VITS_DTE_MAX_DEVID_OFFSET);
>> }
>>
>> -u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
>> +static u32 compute_next_eventid_offset(struct list_head *h, struct its_ite *ite)
>> {
>> struct list_head *e = &ite->ite_list;
>> struct its_ite *next;
>> @@ -1737,8 +1738,8 @@ typedef int (*entry_fn_t)(struct vgic_its *its, u32 id, void *entry,
>> *
>> * Return: < 0 on error, 1 if last element identified, 0 otherwise
>> */
>> -int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
>> - int start_id, entry_fn_t fn, void *opaque)
>> +static int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
>> + int start_id, entry_fn_t fn, void *opaque)
>> {
>> void *entry = kzalloc(esz, GFP_KERNEL);
>> struct kvm *kvm = its->dev->kvm;
>> @@ -1773,6 +1774,127 @@ int lookup_table(struct vgic_its *its, gpa_t base, int size, int esz,
>> }
>>
>> /**
>> + * vgic_its_save_ite - Save an interrupt translation entry at @gpa
>> + */
>> +static int vgic_its_save_ite(struct vgic_its *its, struct its_device *dev,
>> + struct its_ite *ite, gpa_t gpa, int ite_esz)
>> +{
>> + struct kvm *kvm = its->dev->kvm;
>> + u32 next_offset;
>> + u64 val;
>> +
>> + next_offset = compute_next_eventid_offset(&dev->itt_head, ite);
>> + val = ((u64)next_offset << KVM_ITS_ITE_NEXT_SHIFT) |
>> + ((u64)ite->lpi << KVM_ITS_ITE_PINTID_SHIFT) |
>> + ite->collection->collection_id;
>> + val = cpu_to_le64(val);
>> + return kvm_write_guest(kvm, gpa, &val, ite_esz);
>> +}
>> +
>> +/**
>> + * vgic_its_restore_ite - restore an interrupt translation entry
>> + * @event_id: id used for indexing
>> + * @ptr: pointer to the ITE entry
>> + * @opaque: pointer to the its_device
>> + * @next: id offset to the next entry
>> + */
>> +static int vgic_its_restore_ite(struct vgic_its *its, u32 event_id,
>> + void *ptr, void *opaque, u32 *next)
>> +{
>> + struct its_device *dev = (struct its_device *)opaque;
>> + struct its_collection *collection;
>> + struct kvm *kvm = its->dev->kvm;
>> + u64 val, *p = (u64 *)ptr;
>
> nit: initializations on separate line (and possible do that just above
> assigning val).
done
>
>> + struct vgic_irq *irq;
>> + u32 coll_id, lpi_id;
>> + struct its_ite *ite;
>> + int ret;
>> +
>> + val = *p;
>> + *next = 1;
>> +
>> + val = le64_to_cpu(val);
>> +
>> + coll_id = val & KVM_ITS_ITE_ICID_MASK;
>> + lpi_id = (val & KVM_ITS_ITE_PINTID_MASK) >> KVM_ITS_ITE_PINTID_SHIFT;
>> +
>> + if (!lpi_id)
>> + return 0;
>
> are all non-zero LPI IDs valid? Don't we have a wrapper that tests if
> the ID is valid?
no, lpi_id must be >= GIC_MIN_LPI=8192; added that check.
ABI Doc says lpi_id==0 is interpreted as invalid. Other values <
GIC_MIN_LPI cause an -EINVAL error
>
> (looks like it's possible to add LPIs with the INTID range of SPIs, SGIs
> and PPIs here)
>
>> +
>> + *next = val >> KVM_ITS_ITE_NEXT_SHIFT;
>
> Don't we need to validate this somehow since it will presumably be used
> to forward a pointer somehow by the caller?
checked against max number of eventids supported by the device
>
>> +
>> + collection = find_collection(its, coll_id);
>> + if (!collection)
>> + return -EINVAL;
>> +
>> + ret = vgic_its_alloc_ite(dev, &ite, collection,
>> + lpi_id, event_id);
>> + if (ret)
>> + return ret;
>> +
>> + irq = vgic_add_lpi(kvm, lpi_id);
>> + if (IS_ERR(irq))
>> + return PTR_ERR(irq);
>> + ite->irq = irq;
>> +
>> + /* restore the configuration of the LPI */
>> + ret = update_lpi_config(kvm, irq, NULL);
>> + if (ret)
>> + return ret;
>> +
>> + update_affinity_ite(kvm, ite);
>> + return 0;
>> +}
>> +
>> +static int vgic_its_ite_cmp(void *priv, struct list_head *a,
>> + struct list_head *b)
>> +{
>> + struct its_ite *itea = container_of(a, struct its_ite, ite_list);
>> + struct its_ite *iteb = container_of(b, struct its_ite, ite_list);
>> +
>> + if (itea->event_id < iteb->event_id)
>> + return -1;
>> + else
>> + return 1;
>> +}
>> +
>> +int vgic_its_save_itt(struct vgic_its *its, struct its_device *device)
>> +{
>> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> + gpa_t base = device->itt_addr;
>> + struct its_ite *ite;
>> + int ret, ite_esz = abi->ite_esz;
>
> nit: initializations on separate line
OK
>
>> +
>> + list_sort(NULL, &device->itt_head, vgic_its_ite_cmp);
>> +
>> + list_for_each_entry(ite, &device->itt_head, ite_list) {
>> + gpa_t gpa = base + ite->event_id * ite_esz;
>> +
>> + ret = vgic_its_save_ite(its, device, ite, gpa, ite_esz);
>> + if (ret)
>> + return ret;
>> + }
>> + return 0;
>> +}
>> +
>> +int vgic_its_restore_itt(struct vgic_its *its, struct its_device *dev)
>> +{
>> + const struct vgic_its_abi *abi = vgic_its_get_abi(its);
>> + gpa_t base = dev->itt_addr;
>> + int ret, ite_esz = abi->ite_esz;
>> + size_t max_size = BIT_ULL(dev->nb_eventid_bits) * ite_esz;
>
> nit: initializations on separate line
OK
>
>> +
>> + ret = lookup_table(its, base, max_size, ite_esz, 0,
>> + vgic_its_restore_ite, dev);
>
> nit: extra white space
>
>> +
>> + if (ret < 0)
>> + return ret;
>> +
>> + /* if the last element has not been found we are in trouble */
>> + return ret ? 0 : -EINVAL;
>
> hmm, these are values potentially created by the guest in guest RAM,
> right? So do we really abort migration and return an error to userspace
> in this case?
So we discussed with Peter/dave we shouldn't abort() in qemu in case of
such error. The restore table IOCTL will return an error. Up to qemu to
print the error. Destination guest will not be functional though.
Thanks
Eric
>
> Also, this comment doesn't really tell me what this situation is and how
> we handle things...
>
>> +}
>> +
>> +/**
>> * vgic_its_save_device_tables - Save the device table and all ITT
>> * into guest RAM
>> */
>> diff --git a/virt/kvm/arm/vgic/vgic.h b/virt/kvm/arm/vgic/vgic.h
>> index 56e57c1..ce57fbd 100644
>> --- a/virt/kvm/arm/vgic/vgic.h
>> +++ b/virt/kvm/arm/vgic/vgic.h
>> @@ -81,6 +81,10 @@
>> #define KVM_ITS_CTE_VALID_MASK BIT_ULL(63)
>> #define KVM_ITS_CTE_RDBASE_SHIFT 16
>> #define KVM_ITS_CTE_ICID_MASK GENMASK_ULL(15, 0)
>> +#define KVM_ITS_ITE_NEXT_SHIFT 48
>> +#define KVM_ITS_ITE_PINTID_SHIFT 16
>> +#define KVM_ITS_ITE_PINTID_MASK GENMASK_ULL(47, 16)
>> +#define KVM_ITS_ITE_ICID_MASK GENMASK_ULL(15, 0)
>>
>> static inline bool irq_is_pending(struct vgic_irq *irq)
>> {
>> --
>> 2.5.5
>>
>
> Thanks,
> -Christoffer
>
^ permalink raw reply
* [PATCH] [RFC] ARM: dts: imx6sx-sdb: Drop OPP hackery
From: Fabio Estevam @ 2017-05-03 16:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170425164224.26537-1-marex@denx.de>
On Tue, Apr 25, 2017 at 1:42 PM, Marek Vasut <marex@denx.de> wrote:
> The imx6sx-sdb has one power supply that drives both VDDARM_IN
> and VDDSOC_IN, which is the sw1a regulator on the PFUZE PMIC.
> Connect both inputs to the sw1a regulator on the PMIC and drop
> the OPP hackery which is no longer needed as the power framework
> will take care of the regulator configuration as needed.
>
> Signed-off-by: Marek Vasut <marex@denx.de>
> Cc: Fabio Estevam <fabio.estevam@nxp.com>
> Cc: Shawn Guo <shawnguo@kernel.org>
Reviewed-by: Fabio Estevam <fabio.estevam@nxp.com>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox