* [PATCH] arm64: dts: allwinner: a64: bananapi-m64: Add LED device node
From: Chen-Yu Tsai @ 2017-12-05 13:00 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205100511.ohxcqlrozxfgq6id@flea.lan>
On Tue, Dec 5, 2017 at 6:05 PM, Maxime Ripard
<maxime.ripard@free-electrons.com> wrote:
> Hi,
>
> On Sat, Dec 02, 2017 at 12:27:33AM +0800, Chen-Yu Tsai wrote:
>> The Bananapi-M64 has 3 LEDS in red, green, and blue. These are toggled
>> via GPIO lines, which drive transistors that control current across the
>> LEDS. The red LED is by default on, via an additional pull-up on the
>> control line. We consider this means that it is a power indicator.
>> So we set the "default-on" property for it.
>>
>> The pingroups the GPIO lines belong to require external regulators be
>> enabled to be able to drive the GPIO high. These regulators also have
>> other purposes. However the pin controller does not have bindings for
>> regulators. Here we just set them to always-on.
>
> I guess we should take the opportunity to do just that.
>
> We have been deferring this for quite some time now, this is a perfect
> occasion to do it once and for all :)
True. But right now I don't see an elegant solution. What is the purpose
of having the regulator tied to pinctrl / GPIO? You can't have the pinctrl
driver asking for the regulator at probe time, as it might not be available
or even have a cyclic dependency (because the PMIC is I2C driven, which
needs an I2C controller, which needs the pinctrl). If you defer fetching
the regulator to a later point, you might end up with an inconsistent state.
Again with the I2C driven regulator example, what happens if the regulator
core decides to turn the regulator off before the pinctrl side has a chance
to take a reference and enable it?
Regards
ChenYu
^ permalink raw reply
* Applied "ASoC: atmel-classd: select correct Kconfig symbol" to the asoc tree
From: Nicolas Ferre @ 2017-12-05 12:52 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205124803.D380E44006B@finisterre.ee.mobilebroadband>
On 05/12/2017 at 13:48, Mark Brown wrote:
> The patch
>
> ASoC: atmel-classd: select correct Kconfig symbol
>
> has been applied to the asoc tree at
>
> https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
Mark,
Actually the discussion is still ongoing regarding these issues and this
fix isn't the proper one (aka NACK).
Is an incremental patch has to be prepared or do you remove this patch?
Thanks, regards,
Nicolas
> All being well this means that it will be integrated into the linux-next
> tree (usually sometime in the next 24 hours) and sent to Linus during
> the next merge window (or sooner if it is a bug fix), however if
> problems are discovered then the patch may be dropped or reverted.
>
> You may get further e-mails resulting from automated or manual testing
> and review of the tree, please engage with people reporting problems and
> send followup patches addressing any issues that are reported if needed.
>
> If any updates are required or you are submitting further changes they
> should be sent as incremental updates against current git, existing
> patches will not be replaced.
>
> Please add any relevant lists and maintainers to the CCs when replying
> to this mail.
>
> Thanks,
> Mark
>
>>From 7e3dba272e5ef5b38fba8710f98b4b3da7232ea5 Mon Sep 17 00:00:00 2001
> From: Arnd Bergmann <arnd@arndb.de>
> Date: Tue, 5 Dec 2017 11:09:38 +0100
> Subject: [PATCH] ASoC: atmel-classd: select correct Kconfig symbol
>
> Commit 061981ff8cc8 ("ASoC: atmel: properly select dma driver state")
> changed the way that the dependencies are handled, but then the
> Class D amplifier support got merged, which used the old method.
>
> This seems to have triggered a very rare randconfig condition for me
> now, leading to a link error:
>
> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
> atmel_ssc_dai.c:(.text+0x79c): undefined reference to `atmel_pcm_dma_platform_register'
> atmel_ssc_dai.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_register'
> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
> atmel_ssc_dai.c:(.text+0xf24): undefined reference to `atmel_pcm_dma_platform_unregister'
> atmel_ssc_dai.c:(.text+0xf24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_unregister'
>
> Changing it to select SND_ATMEL_SOC_SSC_DMA as intended rather than
> SND_ATMEL_SOC_DMA directly makes it work again.
>
> Fixes: e0a25b6d1862 ("ASoC: atmel-classd: add the Audio Class D Amplifier")
> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
> Signed-off-by: Mark Brown <broonie@kernel.org>
> ---
> sound/soc/atmel/Kconfig | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
> index 4a56f3dfba51..2d998e5c4fb5 100644
> --- a/sound/soc/atmel/Kconfig
> +++ b/sound/soc/atmel/Kconfig
> @@ -64,7 +64,7 @@ config SND_AT91_SOC_SAM9X5_WM8731
> config SND_ATMEL_SOC_CLASSD
> tristate "Atmel ASoC driver for boards using CLASSD"
> depends on ARCH_AT91 || COMPILE_TEST
> - select SND_ATMEL_SOC_DMA
> + select SND_ATMEL_SOC_SSC_DMA
> select REGMAP_MMIO
> help
> Say Y if you want to add support for Atmel ASoC driver for boards using
>
--
Nicolas Ferre
^ permalink raw reply
* Applied "ASoC: atmel-classd: select correct Kconfig symbol" to the asoc tree
From: Mark Brown @ 2017-12-05 12:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205124803.D380E44006B@finisterre.ee.mobilebroadband>
On Tue, Dec 05, 2017 at 12:48:03PM +0000, Mark Brown wrote:
> The patch
>
> ASoC: atmel-classd: select correct Kconfig symbol
Following the subsequent discussion I'll drop this one.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/0cd85881/attachment.sig>
^ permalink raw reply
* Applied "ASoC: atmel-classd: select correct Kconfig symbol" to the asoc tree
From: Mark Brown @ 2017-12-05 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205101000.968887-1-arnd@arndb.de>
The patch
ASoC: atmel-classd: select correct Kconfig symbol
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From d20957ef48c3c0c37e44c5385baf1cdfd132f0db Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 5 Dec 2017 11:09:38 +0100
Subject: [PATCH] ASoC: atmel-classd: select correct Kconfig symbol
Commit 061981ff8cc8 ("ASoC: atmel: properly select dma driver state")
changed the way that the dependencies are handled, but then the
Class D amplifier support got merged, which used the old method.
This seems to have triggered a very rare randconfig condition for me
now, leading to a link error:
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
atmel_ssc_dai.c:(.text+0x79c): undefined reference to `atmel_pcm_dma_platform_register'
atmel_ssc_dai.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_register'
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
atmel_ssc_dai.c:(.text+0xf24): undefined reference to `atmel_pcm_dma_platform_unregister'
atmel_ssc_dai.c:(.text+0xf24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_unregister'
Changing it to select SND_ATMEL_SOC_SSC_DMA as intended rather than
SND_ATMEL_SOC_DMA directly makes it work again.
Fixes: e0a25b6d1862 ("ASoC: atmel-classd: add the Audio Class D Amplifier")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/atmel/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 4a56f3dfba51..2d998e5c4fb5 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -64,7 +64,7 @@ config SND_AT91_SOC_SAM9X5_WM8731
config SND_ATMEL_SOC_CLASSD
tristate "Atmel ASoC driver for boards using CLASSD"
depends on ARCH_AT91 || COMPILE_TEST
- select SND_ATMEL_SOC_DMA
+ select SND_ATMEL_SOC_SSC_DMA
select REGMAP_MMIO
help
Say Y if you want to add support for Atmel ASoC driver for boards using
--
2.15.0
^ permalink raw reply related
* Applied "ASoC: atmel-classd: select correct Kconfig symbol" to the asoc tree
From: Mark Brown @ 2017-12-05 12:48 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205101000.968887-1-arnd@arndb.de>
The patch
ASoC: atmel-classd: select correct Kconfig symbol
has been applied to the asoc tree at
https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git
All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.
You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.
If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.
Please add any relevant lists and maintainers to the CCs when replying
to this mail.
Thanks,
Mark
>From 7e3dba272e5ef5b38fba8710f98b4b3da7232ea5 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@arndb.de>
Date: Tue, 5 Dec 2017 11:09:38 +0100
Subject: [PATCH] ASoC: atmel-classd: select correct Kconfig symbol
Commit 061981ff8cc8 ("ASoC: atmel: properly select dma driver state")
changed the way that the dependencies are handled, but then the
Class D amplifier support got merged, which used the old method.
This seems to have triggered a very rare randconfig condition for me
now, leading to a link error:
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
atmel_ssc_dai.c:(.text+0x79c): undefined reference to `atmel_pcm_dma_platform_register'
atmel_ssc_dai.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_register'
sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
atmel_ssc_dai.c:(.text+0xf24): undefined reference to `atmel_pcm_dma_platform_unregister'
atmel_ssc_dai.c:(.text+0xf24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_unregister'
Changing it to select SND_ATMEL_SOC_SSC_DMA as intended rather than
SND_ATMEL_SOC_DMA directly makes it work again.
Fixes: e0a25b6d1862 ("ASoC: atmel-classd: add the Audio Class D Amplifier")
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
Signed-off-by: Mark Brown <broonie@kernel.org>
---
sound/soc/atmel/Kconfig | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 4a56f3dfba51..2d998e5c4fb5 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -64,7 +64,7 @@ config SND_AT91_SOC_SAM9X5_WM8731
config SND_ATMEL_SOC_CLASSD
tristate "Atmel ASoC driver for boards using CLASSD"
depends on ARCH_AT91 || COMPILE_TEST
- select SND_ATMEL_SOC_DMA
+ select SND_ATMEL_SOC_SSC_DMA
select REGMAP_MMIO
help
Say Y if you want to add support for Atmel ASoC driver for boards using
--
2.15.0
^ permalink raw reply related
* [PATCH] ASoC: atmel-classd: select correct Kconfig symbol
From: Alexandre Belloni @ 2017-12-05 12:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK8P3a29G4T1DbkjwhEqa6cSVQL77z0jW0znMX47tqd5vM-P9Q@mail.gmail.com>
On 05/12/2017 at 12:13:41 +0100, Arnd Bergmann wrote:
> On Tue, Dec 5, 2017 at 11:57 AM, Alexandre Belloni
> <alexandre.belloni@free-electrons.com> wrote:
> > On 05/12/2017 at 11:09:38 +0100, Arnd Bergmann wrote:
> >> Commit 061981ff8cc8 ("ASoC: atmel: properly select dma driver state")
> >> changed the way that the dependencies are handled, but then the
> >> Class D amplifier support got merged, which used the old method.
> >>
> >> This seems to have triggered a very rare randconfig condition for me
> >> now, leading to a link error:
> >>
> >> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
> >> atmel_ssc_dai.c:(.text+0x79c): undefined reference to `atmel_pcm_dma_platform_register'
> >> atmel_ssc_dai.c:(.text+0x79c): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_register'
> >> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
> >> atmel_ssc_dai.c:(.text+0xf24): undefined reference to `atmel_pcm_dma_platform_unregister'
> >> atmel_ssc_dai.c:(.text+0xf24): relocation truncated to fit: R_AARCH64_CALL26 against undefined symbol `atmel_pcm_dma_platform_unregister'
> >>
> >> Changing it to select SND_ATMEL_SOC_SSC_DMA as intended rather than
> >> SND_ATMEL_SOC_DMA directly makes it work again.
> >>
> >> Fixes: e0a25b6d1862 ("ASoC: atmel-classd: add the Audio Class D Amplifier")
> >> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
> > Acked-by: Alexandre Belloni <alexandre.belloni@free-electrons.com>
>
> Unfortunately, my testing just found a new problem with this patch
> applied, I had
> not run enough randconfig tests on top of it:
>
> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_set_audio':
> atmel_ssc_dai.c:(.text+0x73c): undefined reference to `ssc_request'
> sound/soc/atmel/atmel_ssc_dai.o: In function `atmel_ssc_put_audio':
> atmel_ssc_dai.c:(.text+0x7be): undefined reference to `ssc_free'
>
> This is for a configuration with SND_ATMEL_SOC_CLASSD=y
> and CONFIG_ATMEL_SSC=n. Could you tell me whether that is a
> sensible configuration that should work, or whether we need a dependency
> on ATMEL_SSC in SND_ATMEL_SOC_CLASSD? I can't really tell
> from the source code, but you probably know the answer.
>
Ok, does that solve both randconfigs?
diff --git a/sound/soc/atmel/Kconfig b/sound/soc/atmel/Kconfig
index 4a56f3dfba51..dcee145dd179 100644
--- a/sound/soc/atmel/Kconfig
+++ b/sound/soc/atmel/Kconfig
@@ -64,7 +64,7 @@ config SND_AT91_SOC_SAM9X5_WM8731
config SND_ATMEL_SOC_CLASSD
tristate "Atmel ASoC driver for boards using CLASSD"
depends on ARCH_AT91 || COMPILE_TEST
- select SND_ATMEL_SOC_DMA
+ select SND_SOC_GENERIC_DMAENGINE_PCM
select REGMAP_MMIO
help
Say Y if you want to add support for Atmel ASoC driver for boards using
--
Alexandre Belloni, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply related
* [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT
From: Ard Biesheuvel @ 2017-12-05 12:45 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205122757.GW22781@e103592.cambridge.arm.com>
> On 5 Dec 2017, at 12:28, Dave Martin <Dave.Martin@arm.com> wrote:
>
>> On Mon, Dec 04, 2017 at 12:26:37PM +0000, Ard Biesheuvel wrote:
>> Add a support macro to conditionally yield the NEON (and thus the CPU)
>> that may be called from the assembler code. Given that especially the
>> instruction based accelerated crypto code may use very tight loops, add
>> some parametrization so that the TIF_NEED_RESCHED flag test is only
>> executed every so many loop iterations.
>>
>> In some cases, yielding the NEON involves saving and restoring a non
>> trivial amount of context (especially in the CRC folding algorithms),
>> and so the macro is split into two, and the code in between is only
>> executed when the yield path is taken, allowing the contex to be preserved.
>> The second macro takes a label argument that marks the resume-from-yield
>> path, which should restore the preserved context again.
>>
>> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
>> ---
>> arch/arm64/include/asm/assembler.h | 50 ++++++++++++++++++++
>> 1 file changed, 50 insertions(+)
>>
>> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
>> index aef72d886677..917b026d3e00 100644
>> --- a/arch/arm64/include/asm/assembler.h
>> +++ b/arch/arm64/include/asm/assembler.h
>> @@ -512,4 +512,54 @@ alternative_else_nop_endif
>> #endif
>> .endm
>>
>> +/*
>> + * yield_neon - check whether to yield to another runnable task from
>> + * kernel mode NEON code (running with preemption disabled)
>> + *
>> + * - Check whether the preempt count is exactly 1, in which case disabling
>> + * preemption once will make the task preemptible. If this is not the case,
>> + * yielding is pointless.
>> + * - Check whether TIF_NEED_RESCHED is set, and if so, disable and re-enable
>> + * kernel mode NEON (which will trigger a reschedule), and branch to the
>> + * yield fixup code at @lbl.
>> + */
>> + .macro yield_neon, lbl:req, ctr, order, stride, loop
>> + yield_neon_pre \ctr, \order, \stride, \loop
>> + yield_neon_post \lbl
>> + .endm
>> +
>> + .macro yield_neon_pre, ctr, order=0, stride, loop=4444f
>> +#ifdef CONFIG_PREEMPT
>> + /*
>> + * With some algorithms, it makes little sense to poll the
>> + * TIF_NEED_RESCHED flag after every iteration, so only perform
>> + * the check every 2^order strides.
>> + */
>> + .if \order > 1
>> + .if (\stride & (\stride - 1)) != 0
>> + .error "stride should be a power of 2"
>> + .endif
>> + tst \ctr, #((1 << \order) * \stride - 1) & ~(\stride - 1)
>> + b.ne \loop
>> + .endif
>
> I'm not sure what baking in this check gives us, and this seems to
> conflate two rather different things: yielding and defining a
> "heartbeat" frequency for the calling code.
>
> Can we separate out the crypto-loop-helper semantics from the yield-
> neon stuff?
>
Fair enough. I incorporated the check here so it disappears from the code entirely when !CONFIG_PREEMPT, because otherwise, you end up with a sequence that is mispredicted every # iterations without any benefit.
I guess i could macroise that separately though.
> If we had
>
> if_cond_yield_neon
> // patchup code
> endif_yield_neon
>
> then the caller is free to conditionally branch over that as appropriate
> like
>
> loop:
> // crypto stuff
> tst x0, #0xf
> b.ne loop
>
> if_cond_yield_neon
> // patchup code
> endif_cond_yield_neon
>
> b loop
>
> I think this is clearer than burying checks and branches in a macro that
> is trying to be generic.
>
Agreed.
> Label arguments can be added to elide some branches of course, at a
> corresponding cost to clarity... in the common case the cache will
> be hot and the branches won't be mispredicted though. Is it really
> worth it?
>
Perhaps not. And i have not made any attempts yet to benchmark at great detail, given that i need some feedback from the rt crowd first whether this is likely to work as desired.
>> +
>> + get_thread_info x0
>> + ldr w1, [x0, #TSK_TI_PREEMPT]
>> + ldr x0, [x0, #TSK_TI_FLAGS]
>> + cmp w1, #1 // == PREEMPT_OFFSET
>
> asm-offsets?
>
This is not an offset in that regard, but the header that defines it is not asm safe
> [...]
>
> Cheers
> ---Dave
^ permalink raw reply
* [PATCH v6 6/8] KVM: arm/arm64: Support VGIC dist pend/active changes for mapped IRQs
From: Andrew Jones @ 2017-12-05 12:43 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204200506.3224-7-cdall@kernel.org>
On Mon, Dec 04, 2017 at 09:05:04PM +0100, Christoffer Dall wrote:
> +/* Must be called with irq->irq_lock held */
> +static void vgic_hw_irq_change_active(struct kvm_vcpu *vcpu, struct vgic_irq *irq,
> + bool active, bool is_uaccess)
> +{
> + if (!is_uaccess)
> + irq->active = active;;
> +
> + if (!is_uaccess)
> + vgic_irq_set_phys_active(irq, active);
> +}
> +
Missed one.
drew
^ permalink raw reply
* [PATCH 3/3] arm64/sve: KVM: Avoid dereference of dead task during guest entry
From: Dave Martin @ 2017-12-05 12:40 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205094350.GJ32397@cbox>
On Tue, Dec 05, 2017 at 10:43:50AM +0100, Christoffer Dall wrote:
> Hi Dave,
>
> On Mon, Dec 04, 2017 at 03:36:50PM +0000, Dave Martin wrote:
> > On Mon, Dec 04, 2017 at 01:53:21PM +0000, Ard Biesheuvel wrote:
> > > On 1 December 2017 at 15:19, Dave Martin <Dave.Martin@arm.com> wrote:
> > > > When deciding whether to invalidate FPSIMD state cached in the cpu,
> > > > the backend function sve_flush_cpu_state() attempts to dereference
> > > > __this_cpu_read(fpsimd_last_state). However, this is not safe:
> > > > there is no guarantee that the pointer is still valid, because the
> > > > task could have exited in the meantime. For this reason, this
> > > > percpu pointer should only be assigned or compared, never
> > > > dereferenced.
> > > >
> > >
> > > Doesn't that mean the pointer could also be pointing to the
> > > fpsimd_state of a newly created task that is completely unrelated?
> > > IOW, are you sure comparison is safe?
> >
> > There are more conditions: the only place the determination is
> > made is for next, in fpsimd_thread_switch(next).
> >
> >
> > However, I can see your concern and I'm not sure how/if it is
> > resolved.
> >
> > For the worst case, let's assume that some child forks off but
> > doesn't enter userspace yet, while another task round-robins
> > across all CPUs, interspersed with tasks that don't enter userspace.
> >
> > So, we end up with
> >
> > All cpu < NR_CPUS . per_cpu(fpsimd_last_state, cpu) == T.
> >
> > Now, if T dies and a new task is allocated the same task_struct pointer,
> > then the _new_ T is guaranteed to get scheduled in on a CPU whose
> > per_cpu(fpsmid_last_state) == T.
> >
> > Thus, new T can pick up old T's regs _unless_ new T's fpsimd_state.cpu
> > is invalid (i.e., NR_CPUS).
> >
> > This is a separate bug from the one addressed by this patch though.
> > We can't go and harvest the bad pointers when old T exits, because
> > this might race new T being scheduled for real -- in any case it
> > would involve iterating over all CPUs which sounds racy and
> > inefficient.
> >
> >
> > So, I'd say we _must_ call fpsimd_flush_task_state() for every new
> > task. This may result in a redundant reload of the state, but this
> > is what would happen anyway if the pointers did not alias.
> >
> > Does this sound real to you? If so, I'll try to write something.
> >
> > And does this patch look reasonable to fix what it's trying to fix?
> >
> >
> > I wonder whether arch/arm has the same bug actually, since the kernel-
> > mode NEON logic was modelled from there IIUC (?)
> >
> Isn't this the common kernel problem of pid reuse?
It's a problem of <task identifier> reuse, so sort of.
> It seems holding a reference to a struct pid would solve your problems.
> See include/linux/pid.h.
>
> That might also make the code more intuitive and prevent future attempts
> of dereferencing potentially dead data structures.
If we want use the same mechanism to track fpsimd contexts that are not
user task contexts in the future, then that wouldn't work.
In particular, I'd like to track vcpu fpsimd contexts in the same way
as task fpsimd contexts in the future: having two different mechanisms
adds cruft and inefficiency and/or bugs.
I'll look at the struct pid thing and have a think.
Cheers
---Dave
^ permalink raw reply
* [PATCH v9 3/5] perf utils: use pmu->is_uncore to detect PMU UNCORE devices
From: Jin, Yao @ 2017-12-05 12:35 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d576d4c6-663c-dfc1-5618-3fa7c5102e7a@linux.intel.com>
A quick test with the new patch 'fix_json_v9_2.patch' shows it working.
See the log:
root at skl:/tmp# perf stat --per-thread -p 10322 -M CPI,IPC
^C
Performance counter stats for process id '10322':
vmstat-10322 1,879,654 inst_retired.any
# 0.8 CPI
vmstat-10322 1,565,807 cycles
vmstat-10322 1,879,654 inst_retired.any
# 1.2 IPC
vmstat-10322 1,565,807 cpu_clk_unhalted.thread
2.850291804 seconds time elapsed
Thanks for fixing it quickly.
Thanks
Jin Yao
On 12/5/2017 3:23 PM, Jin, Yao wrote:
> Hi,
>
> I applied the diff but it's failed.
>
> jinyao at skl:~/skl-ws/perf-dev/lck-4594/src$ patch -p1 < 1.pat
> patching file tools/perf/util/pmu.c
> patch: **** malformed patch at line 41: *head, struct perf_pmu *pmu)
>
> Could you send the patch as attachment to me in another mail thread?
>
> to yao.jin at linux.intel.com
> cc yao.jin at intel.com
>
> Thanks
> Jin Yao
>
> On 12/5/2017 3:12 PM, Ganapatrao Kulkarni wrote:
>> diff --git a/tools/perf/util/pmu.c b/tools/perf/util/pmu.c
>> index 5ad8a18..57e38fd 100644
>> --- a/tools/perf/util/pmu.c
>> +++ b/tools/perf/util/pmu.c
>> @@ -538,6 +538,34 @@ static bool pmu_is_uncore(const char *name)
>> ? }
>>
>> ? /*
>> + *? PMU CORE devices have different name other than cpu in sysfs on some
>> + *? platforms. looking for possible sysfs files to identify as core
>> device.
>> + */
>> +static int is_pmu_core(const char *name)
>> +{
>> + struct stat st;
>> + char path[PATH_MAX];
>> + const char *sysfs = sysfs__mountpoint();
>> +
>> + if (!sysfs)
>> + return 0;
>> +
>> + /* Look for cpu sysfs (x86 and others) */
>> + scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/cpu", sysfs);
>> + if ((stat(path, &st) == 0) &&
>> + (strncmp(name, "cpu", strlen("cpu")) == 0))
>> + return 1;
>> +
>> + /* Look for cpu sysfs (specific to arm) */
>> + scnprintf(path, PATH_MAX, "%s/bus/event_source/devices/%s/cpus",
>> + sysfs, name);
>> + if (stat(path, &st) == 0)
>> + return 1;
>> +
>> + return 0;
>> +}
>> +
>> +/*
>> ?? * Return the CPU id as a raw string.
>> ?? *
>> ?? * Each architecture should provide a more precise id string that
>> @@ -641,7 +669,7 @@ static void pmu_add_cpu_aliases(struct list_head
>> *head, struct perf_pmu *pmu)
>> ?? break;
>> ?? }
>>
>> - if (pmu->is_uncore) {
>> + if (!is_pmu_core(name)) {
>> ?? /* check for uncore devices */
>> ?? if (pe->pmu == NULL)
>> ?? continue;
^ permalink raw reply
* [PATCH v2 3/3] ARM: davinci: fix mmc entries in DM365's eDMA slaves table
From: Alejandro Mery @ 2017-12-05 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205123458.97837-1-amery@hanoverdisplays.com>
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
arch/arm/mach-davinci/dm365.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 103316f01a22..5ace9380626a 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -868,10 +868,10 @@ static const struct dma_slave_map dm365_edma_map[] = {
{ "spi_davinci.0", "rx", EDMA_FILTER_PARAM(0, 17) },
{ "spi_davinci.3", "tx", EDMA_FILTER_PARAM(0, 18) },
{ "spi_davinci.3", "rx", EDMA_FILTER_PARAM(0, 19) },
- { "dm6441-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
- { "dm6441-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
- { "dm6441-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
- { "dm6441-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
+ { "da830-mmc.0", "rx", EDMA_FILTER_PARAM(0, 26) },
+ { "da830-mmc.0", "tx", EDMA_FILTER_PARAM(0, 27) },
+ { "da830-mmc.1", "rx", EDMA_FILTER_PARAM(0, 30) },
+ { "da830-mmc.1", "tx", EDMA_FILTER_PARAM(0, 31) },
};
static struct edma_soc_info dm365_edma_pdata = {
--
2.15.0
^ permalink raw reply related
* [PATCH v2 2/3] ARM: davinci: Add dma_mask to dm365's eDMA device
From: Alejandro Mery @ 2017-12-05 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205123458.97837-1-amery@hanoverdisplays.com>
as previously done by cef5b0da4019358cb03c9b0a964d4d63cd7deaf6 for other davinci SoCs
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
arch/arm/mach-davinci/dm365.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 9bd17bc77b5c..103316f01a22 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -928,6 +928,7 @@ static struct resource edma_resources[] = {
static const struct platform_device_info dm365_edma_device __initconst = {
.name = "edma",
.id = 0,
+ .dma_mask = DMA_BIT_MASK(32),
.res = edma_resources,
.num_res = ARRAY_SIZE(edma_resources),
.data = &dm365_edma_pdata,
--
2.15.0
^ permalink raw reply related
* [PATCH v2 1/3] ARM: davinci: Use platform_device_register_full() to create pdev for dm365's eDMA
From: Alejandro Mery @ 2017-12-05 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205123458.97837-1-amery@hanoverdisplays.com>
as it was done by 7ab388e85faa97a35d520720269e7c8e00ad54a0 for other davinci SoCs
changes since v1:
* fix typo
Signed-off-by: Alejandro Mery <amery@hanoverdisplays.com>
---
arch/arm/mach-davinci/dm365.c | 20 +++++++++++++-------
1 file changed, 13 insertions(+), 7 deletions(-)
diff --git a/arch/arm/mach-davinci/dm365.c b/arch/arm/mach-davinci/dm365.c
index 8be04ec95adf..9bd17bc77b5c 100644
--- a/arch/arm/mach-davinci/dm365.c
+++ b/arch/arm/mach-davinci/dm365.c
@@ -925,12 +925,13 @@ static struct resource edma_resources[] = {
/* not using TC*_ERR */
};
-static struct platform_device dm365_edma_device = {
- .name = "edma",
- .id = 0,
- .dev.platform_data = &dm365_edma_pdata,
- .num_resources = ARRAY_SIZE(edma_resources),
- .resource = edma_resources,
+static const struct platform_device_info dm365_edma_device __initconst = {
+ .name = "edma",
+ .id = 0,
+ .res = edma_resources,
+ .num_res = ARRAY_SIZE(edma_resources),
+ .data = &dm365_edma_pdata,
+ .size_data = sizeof(dm365_edma_pdata),
};
static struct resource dm365_asp_resources[] = {
@@ -1428,13 +1429,18 @@ int __init dm365_init_video(struct vpfe_config *vpfe_cfg,
static int __init dm365_init_devices(void)
{
+ struct platform_device *edma_pdev;
int ret = 0;
if (!cpu_is_davinci_dm365())
return 0;
davinci_cfg_reg(DM365_INT_EDMA_CC);
- platform_device_register(&dm365_edma_device);
+ edma_pdev = platform_device_register_full(&dm365_edma_device);
+ if (IS_ERR(edma_pdev)) {
+ pr_warn("%s: Failed to register eDMA\n", __func__);
+ return PTR_ERR(edma_pdev);
+ }
platform_device_register(&dm365_mdio_device);
platform_device_register(&dm365_emac_device);
--
2.15.0
^ permalink raw reply related
* [PATCH v2 0/3] ARM: davinci: fix eDMA for DM365
From: Alejandro Mery @ 2017-12-05 12:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204133359.45625-1-amery@hanoverdisplays.com>
Hi, as an intermediate step toward migrating a davinci dm365 based product from 2.6.32.71
to 4.14(.3+) I'm trying to get the dm365 evm (evaluation board) to work
The very first problem is `edma: probe of edma.0 failed with error -5` caused by dm365 not
been included on some refactoring done by Peter Ujfalusi in 2015 which got solved by the
cherry-picking the following changes into dm365.c
* cef5b0da4019 2015-10-14 Peter Ujfalusi ARM: davinci: Add dma_mask to eDMA devices
* 7ab388e85faa 2015-10-14 Peter Ujfalusi ARM: davinci: Use platform_device_register_full() to create pdev for eDMA
Changes since v1:
* fix dumb typo on 1/2
* add extra change (3/3) correcting the name of mmc devices
^ permalink raw reply
* [PATCH 1/3] arm64: KVM: Move CPU ID reg trap setup off the world switch path
From: Dave Martin @ 2017-12-05 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205090915.GI32397@cbox>
On Tue, Dec 05, 2017 at 10:09:15AM +0100, Christoffer Dall wrote:
> On Fri, Dec 01, 2017 at 03:19:40PM +0000, Dave Martin wrote:
> > The HCR_EL2.TID3 flag needs to be set when trapping guest access to
> > the CPU ID registers is required. However, the decision about
> > whether to set this bit does not need to be repeated at every
> > switch to the guest.
> >
> > Instead, it's sufficient to make this decision once and record the
> > outcome.
> >
> > This patch moves the decision to vcpu_reset_hcr() and records the
> > choice made in vcpu->arch.hcr_el2. The world switch code can then
> > load this directly when switching to the guest without the need for
> > conditional logic on the critical path.
> >
> > Signed-off-by: Dave Martin <Dave.Martin@arm.com>
> > Suggested-by: Christoffer Dall <christoffer.dall@linaro.org>
> > Cc: Marc Zyngier <marc.zyngier@arm.com>
>
> Reviewed-by: Christoffer Dall <christoffer.dall@linaro.org>
>
> >
> > ---
> >
> > Note to maintainers: this was discussed on-list [1] prior to the merge
> > window, but this patch implementing the agreed decision hasn't been
> > posted previously.
> >
> > This should be considered a fix for v4.15.
>
> It's actually easier for me to apply this for v4.16 and base my VHE
> optimization patches on it.
If you're happy for this optimisation to be missing for v4.15, I'm fine
with that.
Can I leave it you to pick this up then?
I'll repost the other stuff from this series separately for Will to
take care of.
Cheers
---Dave
^ permalink raw reply
* [PATCH 0/2] ARM: davinci: fix eDMA probing for dm365
From: Peter Ujfalusi @ 2017-12-05 12:31 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204133359.45625-1-amery@hanoverdisplays.com>
Hi,
On 2017-12-04 15:33, Alejandro Mery wrote:
> Hi, as an intermediate step toward migrating a davinci dm365 based product from 2.6.32.71
> to 4.14(.3+) I'm trying to get the dm365 evm (evaluation board) to work
>
> The very first problem is `edma: probe of edma.0 failed with error -5` caused by dm365 not
> been included on some refactoring done by Peter Ujfalusi in 2015 which got solved by the
> cherry-picking the following changes into dm365.c
>
> * cef5b0da4019 2015-10-14 Peter Ujfalusi ARM: davinci: Add dma_mask to eDMA devices
> * 7ab388e85faa 2015-10-14 Peter Ujfalusi ARM: davinci: Use platform_device_register_full() to create pdev for eDMA
Oh, how did I missed them???
Thanks for taking care of dm365!
To both:
Reviewed-by: Peter Ujfalusi <peter.ujfalusi@ti.com>
Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
^ permalink raw reply
* [PATCH v2 3/3] mtd: nand: squash struct nand_buffers into struct nand_chip
From: Masahiro Yamada @ 2017-12-05 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171205125711.74158b3b@bbrezillon>
Hi Boris,
2017-12-05 20:57 GMT+09:00 Boris Brezillon <boris.brezillon@free-electrons.com>:
>>
>>
>> Sorry, I missed to update omap2.c
>>
>> I will send v3.
>
> No need to send a v3, I already fixed it when applying [1].
>
> [1]https://github.com/bbrezillon/linux-0day/commit/59a7bfff7103d48713b2125c3844400301a3d028
>
Thank you for your kind help!
--
Best Regards
Masahiro Yamada
^ permalink raw reply
* [PATCH v2 11/19] arm64: assembler: add macro to conditionally yield the NEON under PREEMPT
From: Dave Martin @ 2017-12-05 12:28 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20171204122645.31535-12-ard.biesheuvel@linaro.org>
On Mon, Dec 04, 2017 at 12:26:37PM +0000, Ard Biesheuvel wrote:
> Add a support macro to conditionally yield the NEON (and thus the CPU)
> that may be called from the assembler code. Given that especially the
> instruction based accelerated crypto code may use very tight loops, add
> some parametrization so that the TIF_NEED_RESCHED flag test is only
> executed every so many loop iterations.
>
> In some cases, yielding the NEON involves saving and restoring a non
> trivial amount of context (especially in the CRC folding algorithms),
> and so the macro is split into two, and the code in between is only
> executed when the yield path is taken, allowing the contex to be preserved.
> The second macro takes a label argument that marks the resume-from-yield
> path, which should restore the preserved context again.
>
> Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
> ---
> arch/arm64/include/asm/assembler.h | 50 ++++++++++++++++++++
> 1 file changed, 50 insertions(+)
>
> diff --git a/arch/arm64/include/asm/assembler.h b/arch/arm64/include/asm/assembler.h
> index aef72d886677..917b026d3e00 100644
> --- a/arch/arm64/include/asm/assembler.h
> +++ b/arch/arm64/include/asm/assembler.h
> @@ -512,4 +512,54 @@ alternative_else_nop_endif
> #endif
> .endm
>
> +/*
> + * yield_neon - check whether to yield to another runnable task from
> + * kernel mode NEON code (running with preemption disabled)
> + *
> + * - Check whether the preempt count is exactly 1, in which case disabling
> + * preemption once will make the task preemptible. If this is not the case,
> + * yielding is pointless.
> + * - Check whether TIF_NEED_RESCHED is set, and if so, disable and re-enable
> + * kernel mode NEON (which will trigger a reschedule), and branch to the
> + * yield fixup code at @lbl.
> + */
> + .macro yield_neon, lbl:req, ctr, order, stride, loop
> + yield_neon_pre \ctr, \order, \stride, \loop
> + yield_neon_post \lbl
> + .endm
> +
> + .macro yield_neon_pre, ctr, order=0, stride, loop=4444f
> +#ifdef CONFIG_PREEMPT
> + /*
> + * With some algorithms, it makes little sense to poll the
> + * TIF_NEED_RESCHED flag after every iteration, so only perform
> + * the check every 2^order strides.
> + */
> + .if \order > 1
> + .if (\stride & (\stride - 1)) != 0
> + .error "stride should be a power of 2"
> + .endif
> + tst \ctr, #((1 << \order) * \stride - 1) & ~(\stride - 1)
> + b.ne \loop
> + .endif
I'm not sure what baking in this check gives us, and this seems to
conflate two rather different things: yielding and defining a
"heartbeat" frequency for the calling code.
Can we separate out the crypto-loop-helper semantics from the yield-
neon stuff?
If we had
if_cond_yield_neon
// patchup code
endif_yield_neon
then the caller is free to conditionally branch over that as appropriate
like
loop:
// crypto stuff
tst x0, #0xf
b.ne loop
if_cond_yield_neon
// patchup code
endif_cond_yield_neon
b loop
I think this is clearer than burying checks and branches in a macro that
is trying to be generic.
Label arguments can be added to elide some branches of course, at a
corresponding cost to clarity... in the common case the cache will
be hot and the branches won't be mispredicted though. Is it really
worth it?
> +
> + get_thread_info x0
> + ldr w1, [x0, #TSK_TI_PREEMPT]
> + ldr x0, [x0, #TSK_TI_FLAGS]
> + cmp w1, #1 // == PREEMPT_OFFSET
asm-offsets?
[...]
Cheers
---Dave
^ permalink raw reply
* [PATCH 1/2] mm: make faultaround produce old ptes
From: Catalin Marinas @ 2017-12-05 12:16 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAADWXX8FmAs1qB9=fsWZjt8xTEnGOAMS=eCHnuDLJrZiX6x=7w@mail.gmail.com>
On Tue, Nov 28, 2017 at 11:45:27AM -0800, Linus Torvalds wrote:
> On Mon, Nov 27, 2017 at 9:07 PM, Vinayak Menon <vinmenon@codeaurora.org> wrote:
> > Making the faultaround ptes old results in a unixbench regression for some
> > architectures [3][4]. But on some architectures it is not found to cause
> > any regression. So by default produce young ptes and provide an option for
> > architectures to make the ptes old.
>
> Ugh. This hidden random behavior difference annoys me.
>
> It should also be better documented in the code if we end up doing it.
>
> The reason x86 seems to prefer young pte's is simply that a TLB lookup
> of an old entry basically causes a micro-fault that then sets the
> accessed bit (using a locked cycle) and then a restart.
>
> Those microfaults are not visible to software, but they are pretty
> expensive in hardware, probably because they basically serialize
> execution as if a real page fault had happened.
In principle it's not that different for ARMv8.1+ but it highly depends
on the microarchitecture details (and we have a lot of variation on
ARM). From a programmer's perspective, old ptes (access flag cleared)
are not allowed to be cached in the TLB, otherwise ptep_clear_flush()
would break. Marking fault-around ptes as young allows the hardware to
speculatively populate the TLB but, again, it's highly microarchitecture
specific and I'm not sure we have a general answer covering the ARM
architecture. Of course, faulting on old ptes is much slower without
hardware AF.
> HOWEVER - and this is the part that annoys me most about the hidden
> behavior - I suspect it ends up being very dependent on
> microarchitectural details in addition to the actual load. So it might
> be more true on some cores than others, and it might be very
> load-dependent. So hiding it as some architectural helper function
> really feels wrong to me. It would likely be better off as a real
> flag, and then maybe we could make the default behavior be set by
> architecture (or even dynamically by the architecture bootup code if
> it turns out to be enough of an issue).
It looks to me like we are trying to work around a vmscan behaviour
visible under memory pressure [1]. The original report doesn't state
whether hardware AF is available (it seems to be tested on a 3.18
Android kernel; hardware AF on arm64 went in 4.6).
In this case there is a trade-off between swapping out potentially hot
pages vs page table walk (either in hardware or via software fault) for
fault-around ptes. This trade-off further depends on whether the
architecture can do hardware access flag or not.
I would be more in favour of some heuristics to dynamically reduce the
fault-around bytes based on the memory pressure rather than choosing
between young or old ptes. Or, if we are to go with old vs young ptes,
make this choice dependent on the memory pressure regardless of whether
the CPU supports hardware accessed bit.
[1] https://lkml.kernel.org/r/1460992636-711-1-git-send-email-vinmenon at codeaurora.org
--
Catalin
^ permalink raw reply
* [PATCH 5/8] ASoC: uniphier: add support for UniPhier AIO driver
From: Mark Brown @ 2017-12-05 12:14 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <002b01d36d84$51d80aa0$f5881fe0$@socionext.com>
On Tue, Dec 05, 2017 at 01:48:39PM +0900, Katsuhiro Suzuki wrote:
Please fix your mail client to word wrap within paragraphs at something
substantially less than 80 columns. Doing this makes your messages much
easier to read and reply to.
> > Is there a mux in the SoC here?
> Sorry for confusing, It's not mux.
> uniphier_srcport_reset() resets HW SRC (sampling rate converter) block.
> Audio data out ports of UniPhier audio system have HW SRC.
Is the SRC just a single block sitting between the DMA and the external
audio port or is there more going on? Some of the other code made me
think the hardware was more flexible than this (all the writing to
registers with names like RXSEL for example).
> > > +#endif /* CONFIG_SND_SOC_UNIPHIER_LD11 */
> > Why is there an ifdef here? There's no other conditional code in here,
> > it seems pointless.
> This config is used to support or not LD11 SoC.
> aio-ld11.c is not build and 'uniphier_aio_ldxx_spec' is undefined if this config is disabled.
>
> aio-ld11.c defines SoC dependent resources (port, HW ring buffer, DMA ch, etc.)
> and fixed settings.
> I know it's better to move such information into device-tree, but register areas of
> UniPhier's audio system is very strange and interleaved. It's hard to split each nodes...
I'd expect this code to be structured more like a library - have a
driver that handles the specific IPs then have it call into a shared
block of code that does the generic bits. Though in this case the
device specific bit looks like a couple of tiny data tables so I'm not
sure it's worth making it conditional or separate at all.
> > This looks awfully like compressed audio support... should there be
> > integration with the compressed audio API/
> Thanks, I'll try it. Is there Documentation in sound/designes/compress-offload.rst?
> And best sample is... Intel's driver?
Yes.
> (Summary)
> I think I should fix as follows:
> - Split DMA, DAI patches from large one
> - Validate parameters in hw_params
> - Add description about HW SRC (or fix bad name 'srcport')
> - Add comments about uniphier_aiodma_irq()
> - Expose clocking and audio routing to userspace, or at the very
> least machine driver configuration
> - Support compress-audio API for S/PDIF
> and post V2.
At least. I do think we need to get to the bottom of how flexible the
hardware is first though.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/23f3b2ab/attachment.sig>
^ permalink raw reply
* [PATCH 4/8] ASoC: uniphier: add support for UniPhier EVEA codec
From: Mark Brown @ 2017-12-05 11:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNAR=-vHN5k6irpaDcAUYcH2kjCXLJpf10RMuq=GZB3huog@mail.gmail.com>
On Tue, Dec 05, 2017 at 09:58:54AM +0900, Masahiro Yamada wrote:
> Indeed ugly,
> but I think this is intentional to make the SPDX line stand out.
>
> Linus suggested this as far as I understood from the following:
> https://patchwork.kernel.org/patch/10016201/
> If you use C++ comment style for the entire block,
> it will not stand out.
It's the first line of the file to make it stand out, if you google
around you can find some other conversation about how C++ comments are
a good idea in general and this might encourage them.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20171205/8dab3739/attachment.sig>
^ permalink raw reply
* [PATCH v2 3/3] mtd: nand: squash struct nand_buffers into struct nand_chip
From: Boris Brezillon @ 2017-12-05 11:57 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAK7LNATKBO=eNHdL_P2MOh7+uRcCjkq+v8+O3DXC5UF3-NGh2Q@mail.gmail.com>
On Tue, 5 Dec 2017 20:49:28 +0900
Masahiro Yamada <yamada.masahiro@socionext.com> wrote:
> 2017-12-05 17:47 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> > struct nand_buffers is malloc'ed in nand_scan_tail() just for
> > containing three pointers. Squash this struct into nand_chip.
> >
> > Move and rename as follows:
> >
> > chip->buffers->ecccalc -> chip->ecc.calc_buf
> > chip->buffers->ecccode -> chip->ecc.code_buf
> > chip->buffers->databuf -> chip->data_buf
> >
> > Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> > ---
> >
>
>
>
>
> > diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> > index dad438c..7870cb1 100644
> > --- a/drivers/mtd/nand/omap2.c
> > +++ b/drivers/mtd/nand/omap2.c
> > @@ -1530,7 +1530,7 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> > const uint8_t *buf, int oob_required, int page)
> > {
> > int ret;
> > - uint8_t *ecc_calc = chip->buffers->ecccalc;
> > + uint8_t *ecc_calc = chip->ecccalc;
> >
> > /* Enable GPMC ecc engine */
> > chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
> > @@ -1568,7 +1568,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> > u32 data_len, const u8 *buf,
> > int oob_required, int page)
> > {
> > - u8 *ecc_calc = chip->buffers->ecccalc;
> > + u8 *ecc_calc = chip->ecccalc;
> > int ecc_size = chip->ecc.size;
> > int ecc_bytes = chip->ecc.bytes;
> > int ecc_steps = chip->ecc.steps;
> > @@ -1605,7 +1605,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> >
> > /* copy calculated ECC for whole page to chip->buffer->oob */
> > /* this include masked-value(0xFF) for unwritten subpages */
> > - ecc_calc = chip->buffers->ecccalc;
> > + ecc_calc = chip->ecccalc;
> > ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
> > chip->ecc.total);
> > if (ret)
> > @@ -1635,8 +1635,8 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> > static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> > uint8_t *buf, int oob_required, int page)
> > {
> > - uint8_t *ecc_calc = chip->buffers->ecccalc;
> > - uint8_t *ecc_code = chip->buffers->ecccode;
> > + uint8_t *ecc_calc = chip->ecccalc;
> > + uint8_t *ecc_code = chip->ecccode;
> > int stat, ret;
> > unsigned int max_bitflips = 0;
> >
>
>
>
> Sorry, I missed to update omap2.c
>
> I will send v3.
No need to send a v3, I already fixed it when applying [1].
[1]https://github.com/bbrezillon/linux-0day/commit/59a7bfff7103d48713b2125c3844400301a3d028
^ permalink raw reply
* [PATCH] soc: qcom: Separate kryo l2 accessors from PMU driver
From: Mark Rutland @ 2017-12-05 11:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <011801d36dbd$7ae34e80$70a9eb80$@codeaurora.org>
On Tue, Dec 05, 2017 at 01:37:47PM +0200, ilialin at codeaurora.org wrote:
> Hello Mark,
>
> > -----Original Message-----
> > From: Mark Rutland [mailto:mark.rutland at arm.com]
> > Sent: Tuesday, December 5, 2017 12:35 PM
> > To: Ilia Lin <ilialin@codeaurora.org>
> > Cc: linux-arm-kernel at lists.infradead.org
> > Subject: Re: [PATCH] soc: qcom: Separate kryo l2 accessors from PMU driver
> >
> > Hi,
> >
> > On Tue, Dec 05, 2017 at 08:33:50AM +0200, Ilia Lin wrote:
> > > The driver provides kernel level API for other drivers to access the
> > > MSM8996 L2 cache registers.
> > > Separating the L2 access code from the PMU driver and making it public
> > > to allow other drivers use it.
> > > The accesses must be separated with a single spinlock, maintained in
> > > this driver.
> > >
> > > Change-Id: I2865e888491e85d678e298279400c371427e30ea
> > > Signed-off-by: Ilia Lin <ilialin@codeaurora.org>
> >
> > What other driver is going to use this?
> >
> > Until there is another driver, I don't see much point in factoring this
> out.
>
> The other driver currently is the CPU clock driver, which needs configuring
> the L2 registers. The clock driver will be submitted through the linux-clk
> list and will depend on the kryo-l2-accessors driver then.
Ok,
Please put the two in a series, and keep me (and Will Deacon) on Cc, so
that we can review both together.
Thanks,
Mark.
^ permalink raw reply
* [PATCH v2 3/3] mtd: nand: squash struct nand_buffers into struct nand_chip
From: Masahiro Yamada @ 2017-12-05 11:49 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1512463636-28934-3-git-send-email-yamada.masahiro@socionext.com>
2017-12-05 17:47 GMT+09:00 Masahiro Yamada <yamada.masahiro@socionext.com>:
> struct nand_buffers is malloc'ed in nand_scan_tail() just for
> containing three pointers. Squash this struct into nand_chip.
>
> Move and rename as follows:
>
> chip->buffers->ecccalc -> chip->ecc.calc_buf
> chip->buffers->ecccode -> chip->ecc.code_buf
> chip->buffers->databuf -> chip->data_buf
>
> Signed-off-by: Masahiro Yamada <yamada.masahiro@socionext.com>
> ---
>
> diff --git a/drivers/mtd/nand/omap2.c b/drivers/mtd/nand/omap2.c
> index dad438c..7870cb1 100644
> --- a/drivers/mtd/nand/omap2.c
> +++ b/drivers/mtd/nand/omap2.c
> @@ -1530,7 +1530,7 @@ static int omap_write_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> const uint8_t *buf, int oob_required, int page)
> {
> int ret;
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> + uint8_t *ecc_calc = chip->ecccalc;
>
> /* Enable GPMC ecc engine */
> chip->ecc.hwctl(mtd, NAND_ECC_WRITE);
> @@ -1568,7 +1568,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> u32 data_len, const u8 *buf,
> int oob_required, int page)
> {
> - u8 *ecc_calc = chip->buffers->ecccalc;
> + u8 *ecc_calc = chip->ecccalc;
> int ecc_size = chip->ecc.size;
> int ecc_bytes = chip->ecc.bytes;
> int ecc_steps = chip->ecc.steps;
> @@ -1605,7 +1605,7 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
>
> /* copy calculated ECC for whole page to chip->buffer->oob */
> /* this include masked-value(0xFF) for unwritten subpages */
> - ecc_calc = chip->buffers->ecccalc;
> + ecc_calc = chip->ecccalc;
> ret = mtd_ooblayout_set_eccbytes(mtd, ecc_calc, chip->oob_poi, 0,
> chip->ecc.total);
> if (ret)
> @@ -1635,8 +1635,8 @@ static int omap_write_subpage_bch(struct mtd_info *mtd,
> static int omap_read_page_bch(struct mtd_info *mtd, struct nand_chip *chip,
> uint8_t *buf, int oob_required, int page)
> {
> - uint8_t *ecc_calc = chip->buffers->ecccalc;
> - uint8_t *ecc_code = chip->buffers->ecccode;
> + uint8_t *ecc_calc = chip->ecccalc;
> + uint8_t *ecc_code = chip->ecccode;
> int stat, ret;
> unsigned int max_bitflips = 0;
>
Sorry, I missed to update omap2.c
I will send v3.
^ permalink raw reply
* [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro
From: Matthias Reichl @ 2017-12-05 11:47 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20170823150351.606ba09f@gandalf.local.home>
On Wed, Aug 23, 2017 at 03:03:51PM -0400, Steven Rostedt wrote:
> On Wed, 23 Aug 2017 11:48:13 -0700
> Kees Cook <keescook@chromium.org> wrote:
>
> > > diff --git a/arch/arm/mm/init.c b/arch/arm/mm/init.c
> > > index ad80548..fd75f38 100644
> > > --- a/arch/arm/mm/init.c
> > > +++ b/arch/arm/mm/init.c
> > > @@ -745,19 +745,29 @@ static int __mark_rodata_ro(void *unused)
> > > return 0;
> > > }
> > >
> > > +static int kernel_set_to_readonly;
> >
> > Adding a comment here might be a good idea, something like:
> >
> > /* Has system boot-up reached mark_rodata_ro() yet? */
>
> I don't mind adding a comment, but the above is rather self explanatory
> (one can easily see that it is set in mark_rodata_ro() with a simple
> search).
>
> If a comment is to be added, something a bit more descriptive of the
> functionality of the variable would be appropriate:
>
> /*
> * Ignore modifying kernel text permissions until the kernel core calls
> * make_rodata_ro() at system start up.
> */
>
> I can resend with the comment, or whoever takes this could add it
> themselves.
Gentle ping: this patch doesn't seem to have landed in upstream
trees yet. Is any more work required?
It would be nice to have this fix added. Just tested next-20171205
on RPi B+, it oopses when the function tracer is enabled during boot.
next-20171205 plus this patch boots up fine.
so long,
Hias
>
> -- Steve
>
>
> >
> > Otherwise:
> >
> > Acked-by: Kees Cook <keescook@chromium.org>
> >
> > > +
> > > void mark_rodata_ro(void)
> > > {
> > > + kernel_set_to_readonly = 1;
> > > +
> > > stop_machine(__mark_rodata_ro, NULL, NULL);
> > > }
> > >
> > > void set_kernel_text_rw(void)
> > > {
> > > + if (!kernel_set_to_readonly)
> > > + return;
> > > +
> > > set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), false,
> > > current->active_mm);
> > > }
> > >
> > > void set_kernel_text_ro(void)
> > > {
> > > + if (!kernel_set_to_readonly)
> > > + return;
> > > +
> > > set_section_perms(ro_perms, ARRAY_SIZE(ro_perms), true,
> > > current->active_mm);
> > > }
> >
> > Does arm64 suffer from a similar condition? (It looks like no, as text
> > patching is done with a fixmap poke.)
> >
> > -Kees
> >
>
^ 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