[PATCH] tty: fix crash in release_tty if tty->port is not set

the kernel crash. Fixes: 2ae0b31e0face ("tty: don't crash in tty_init_dev when missing tty_port") Signed-off-by: Matthias Reichl --- drivers/tty/tty_io.c | 6 -- 1 file changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/tty/tty_io.c b/drivers/tty/tty_io.c index 7a4c02548

Re: Crash when specifying non-existent serial port in speakup / tty_kopen

On Wed, Nov 04, 2020 at 10:30:05PM +0100, Samuel Thibault wrote: > Matthias Reichl, le mer. 04 nov. 2020 22:15:05 +0100, a ecrit: > > > This looks like only a warning, did it actually crash? > > > > Yes, scroll down a bit, the null pointer oops followed almo

Re: Crash when specifying non-existent serial port in speakup / tty_kopen

Hi Samuel, On Wed, Nov 04, 2020 at 09:13:23PM +0100, Samuel Thibault wrote: > Hello, > > Matthias Reichl, le mer. 04 nov. 2020 15:57:37 +0100, a ecrit: > > I initially noticed this oops on x86_64 running kernel 5.4.59 when > > I accidentally mistyped "ttyS0"

Crash when specifying non-existent serial port in speakup / tty_kopen

I initially noticed this oops on x86_64 running kernel 5.4.59 when I accidentally mistyped "ttyS0" as "ttyS9": modprobe speakup_dummy dev=ttyS9 x86_64/5.10-rc2 showed the same behaviour (see below), also 5.9.3 on RPi with the ttyAMA driver. I couldn't make the kernel warn/crash yet by specifying

Re: [PATCH] ASoC: bcm2835: Add enable/disable clock functions

On Wed, Oct 28, 2020 at 01:18:33AM -0700, Allen Martin wrote: > Hi, just checking if you had a chance to review this patch. > > On Sat, Oct 10, 2020 at 12:26 PM Allen Martin wrote: > > > Add functions to control enable/disable of BCLK output of bcm2835 I2S > > controller so that BCLK output

Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component

On Tue, Jan 15, 2019 at 09:41:38PM +, Mark Brown wrote: > On Tue, Jan 15, 2019 at 03:16:57PM -0600, Pierre-Louis Bossart wrote: > > > > Maybe the defer card probe logic needs to be extended to also check if > > > dai_link_name had already been registered (either cpu or cpu_dai_name > > >

Re: [alsa-devel] [PATCH] ASoC: soc-core: Fix null pointer dereference in soc_find_component

On Tue, Jan 15, 2019 at 01:35:07PM -0600, Pierre-Louis Bossart wrote: > > On 1/14/19 6:06 PM, Mark Brown wrote: > > On Fri, Jan 11, 2019 at 03:49:08PM -0600, Pierre-Louis Bossart wrote: > > > > > Adding some traces I can see that the the platform name we use doesn't > > > seem > > > compatible

Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement

On Tue, Jan 15, 2019 at 03:26:42PM +, Jon Hunter wrote: > > On 14/01/2019 23:02, Mark Brown wrote: > > On Fri, Jan 11, 2019 at 09:15:42AM +, Jon Hunter wrote: > >> On 11/01/2019 08:51, Kuninori Morimoto wrote: > > > >>> So, can you agree about these ? > >>> 1) Add enough

Re: [alsa-devel] [PATCH v1 3/3] ASoC: soc-core: fix platform name vs. of_node assignement

Hi Mark, On Sun, Oct 21, 2018 at 12:23:01PM +0100, Mark Brown wrote: > On Fri, Oct 19, 2018 at 11:22:46AM +0100, Jon Hunter wrote: > > > Looking at snd_soc_init_platform(), it seems that the platform pointer > > can be allocated by the machine driver and so if it is not allocated by > > the

Add "regulator: arizona-ldo1: Use correct device to get enable GPIO" to 4.18 stable tree

It seems the arizona-ldo1 ldoena fix hasn't made it into 4.18. It was added to 4.19/mainline, though: commit a9191579ba1086d91842199263e6fe6bb5eec1ba Author: Charles Keepax Date: Tue Jun 19 16:10:00 2018 +0100 regulator: arizona-ldo1: Use correct device to get enable GPIO Could you

Add "regulator: arizona-ldo1: Use correct device to get enable GPIO" to 4.18 stable tree

It seems the arizona-ldo1 ldoena fix hasn't made it into 4.18. It was added to 4.19/mainline, though: commit a9191579ba1086d91842199263e6fe6bb5eec1ba Author: Charles Keepax Date: Tue Jun 19 16:10:00 2018 +0100 regulator: arizona-ldo1: Use correct device to get enable GPIO Could you

[PATCH] kbuild: honor HOSTCFLAGS and HOSTLDFLAGS in libelf test

stem. Fix this by adding HOSTCFLAGS and HOSTLDFLAGS to the libelf check. Signed-off-by: Matthias Reichl --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c9132594860b..b0485fddc554 100644 --- a/Makefile +++ b/Makefile @@ -933,7 +933,7

[PATCH] kbuild: honor HOSTCFLAGS and HOSTLDFLAGS in libelf test

stem. Fix this by adding HOSTCFLAGS and HOSTLDFLAGS to the libelf check. Signed-off-by: Matthias Reichl --- Makefile | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/Makefile b/Makefile index c9132594860b..b0485fddc554 100644 --- a/Makefile +++ b/Makefile @@ -933,7 +933,7

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Fri, Jun 29, 2018 at 11:16:58AM -0400, Steven Rostedt wrote: > On Fri, 29 Jun 2018 16:47:14 +0200 > Matthias Reichl wrote: > > > On Tue, Dec 05, 2017 at 12:14:46PM -0800, Kees Cook wrote: > > > On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux > > >

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Fri, Jun 29, 2018 at 11:16:58AM -0400, Steven Rostedt wrote: > On Fri, 29 Jun 2018 16:47:14 +0200 > Matthias Reichl wrote: > > > On Tue, Dec 05, 2017 at 12:14:46PM -0800, Kees Cook wrote: > > > On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux > > >

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 05, 2017 at 12:14:46PM -0800, Kees Cook wrote: > On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux > wrote: > > On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote: > >> We don't _need_ to, but they're all contiguous, so the ro_perms array > >> used by

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 05, 2017 at 12:14:46PM -0800, Kees Cook wrote: > On Tue, Dec 5, 2017 at 12:09 PM, Russell King - ARM Linux > wrote: > > On Tue, Dec 05, 2017 at 11:35:59AM -0800, Kees Cook wrote: > >> We don't _need_ to, but they're all contiguous, so the ro_perms array > >> used by

Re: [PATCH] regulator: arizona-ldo1: Use correct device to get enable GPIO

scriptor and pass > to the core") > Reported-by: Matthias Reichl > Signed-off-by: Charles Keepax Tested-by: Matthias Reichl > Apologies for missing this again, we should have caught > this in our testing and thanks for reporting it. No problem, and thank you a lot for th

Re: [PATCH] regulator: arizona-ldo1: Use correct device to get enable GPIO

scriptor and pass > to the core") > Reported-by: Matthias Reichl > Signed-off-by: Charles Keepax Tested-by: Matthias Reichl > Apologies for missing this again, we should have caught > this in our testing and thanks for reporting it. No problem, and thank you a lot for th

Regression in 4.18-rc1 caused by regulator: arizona-ldo1: Look up a descriptor and pass to the core

Commit e1739e86f0cb9c48e8745a610e6981a4e24cadad breaks reading the wlf,ldoena property from device tree. This causes ldo1 to stay off and thus arizona device detection to fail: [4.495958] of_get_named_gpiod_flags: parsed 'wlf,reset' property of node '/s oc/spi@7e204000/wm5102@1[0]' - status

Regression in 4.18-rc1 caused by regulator: arizona-ldo1: Look up a descriptor and pass to the core

Commit e1739e86f0cb9c48e8745a610e6981a4e24cadad breaks reading the wlf,ldoena property from device tree. This causes ldo1 to stay off and thus arizona device detection to fail: [4.495958] of_get_named_gpiod_flags: parsed 'wlf,reset' property of node '/s oc/spi@7e204000/wm5102@1[0]' - status

Re: [PATCH v4 0/3] IR decoding using BPF

Hi Sean, On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote: > The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most > widely used IR protocols, but there are many protocols which are not > supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes, >

Re: [PATCH v4 0/3] IR decoding using BPF

Hi Sean, On Fri, May 18, 2018 at 03:07:27PM +0100, Sean Young wrote: > The kernel IR decoders (drivers/media/rc/ir-*-decoder.c) support the most > widely used IR protocols, but there are many protocols which are not > supported[1]. For example, the lirc-remotes[2] repo has over 2700 remotes, >

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 05, 2017 at 01:14:17PM +, Russell King - ARM Linux wrote: > On Tue, Dec 05, 2017 at 12:47:09PM +0100, Matthias Reichl wrote: > > On Wed, Aug 23, 2017 at 03:03:51PM -0400, Steven Rostedt wrote: > > > On Wed, 23 Aug 2017 11:48:13 -0700 > > > Kees Cook &l

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Tue, Dec 05, 2017 at 01:14:17PM +, Russell King - ARM Linux wrote: > On Tue, Dec 05, 2017 at 12:47:09PM +0100, Matthias Reichl wrote: > > On Wed, Aug 23, 2017 at 03:03:51PM -0400, Steven Rostedt wrote: > > > On Wed, 23 Aug 2017 11:48:13 -0700 > > > Kees Cook w

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Wed, Aug 23, 2017 at 03:03:51PM -0400, Steven Rostedt wrote: > On Wed, 23 Aug 2017 11:48:13 -0700 > Kees Cook 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 > > > +++

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

On Wed, Aug 23, 2017 at 03:03:51PM -0400, Steven Rostedt wrote: > On Wed, 23 Aug 2017 11:48:13 -0700 > Kees Cook 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

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

gt; Fixes: d57ea877af38 ("media: rc: per-protocol repeat period") > Cc: <sta...@vger.kernel.org> # 4.14 > Signed-off-by: Sean Young <s...@mess.org> Tested-by: Matthias Reichl <h...@horus.com> I tested this locally with gpio-ir configured to 200ms timeout and we also

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

7af38 ("media: rc: per-protocol repeat period") > Cc: # 4.14 > Signed-off-by: Sean Young Tested-by: Matthias Reichl I tested this locally with gpio-ir configured to 200ms timeout and we also received feedback from 2 users that this change fixed the issue with the ite-cir receiver. ht

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

On Fri, Nov 17, 2017 at 03:52:50PM +0100, Matthias Reichl wrote: > Hi Sean! > > On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote: > > Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), > > double keypresses are reported on the ite-

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

On Fri, Nov 17, 2017 at 03:52:50PM +0100, Matthias Reichl wrote: > Hi Sean! > > On Thu, Nov 16, 2017 at 09:54:51PM +, Sean Young wrote: > > Since commit d57ea877af38 ("media: rc: per-protocol repeat period"), > > double keypresses are reported on the ite-

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

via timeout (sth like timestamp - last_timestamp > protocol_repeat_period) and in that case immediately signalling keyup could help? Could well be that I'm missing somehting important and this is a bad idea. I guess I'd better let you figure something out :) so long, Hias > > Cc: <sta...@vger.kern

Re: [PATCH] media: rc: double keypresses due to timeout expiring to early

via timeout (sth like timestamp - last_timestamp > protocol_repeat_period) and in that case immediately signalling keyup could help? Could well be that I'm missing somehting important and this is a bad idea. I guess I'd better let you figure something out :) so long, Hias > > Cc: # 4.14 &

4.14 regression from commit d57ea877af38 media: rc: per-protocol repeat period

The following commit introduced a regression commit d57ea877af38057b0ef31758cf3b99765dc33695 Author: Sean Young Date: Wed Aug 9 13:19:16 2017 -0400 media: rc: per-protocol repeat period CEC needs a keypress timeout of 550ms, which is too high for the IR protocols.

4.14 regression from commit d57ea877af38 media: rc: per-protocol repeat period

The following commit introduced a regression commit d57ea877af38057b0ef31758cf3b99765dc33695 Author: Sean Young Date: Wed Aug 9 13:19:16 2017 -0400 media: rc: per-protocol repeat period CEC needs a keypress timeout of 550ms, which is too high for the IR protocols. Also fill in

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

tp://lkml.kernel.org/r/20170821153402.7so2u364htvt6...@camel2.lan > Link: https://github.com/raspberrypi/linux/issues/2166#issuecomment-323355145 > Reported-by: Matthias Reichl <h...@horus.com> > Cc: Russell King <li...@armlinux.org.uk> > Cc: Kees Cook <keesc...@chromium.org&

Re: [PATCH] Arm: mm: ftrace: Only set text back to ro after kernel has been marked ro

tp://lkml.kernel.org/r/20170821153402.7so2u364htvt6...@camel2.lan > Link: https://github.com/raspberrypi/linux/issues/2166#issuecomment-323355145 > Reported-by: Matthias Reichl > Cc: Russell King > Cc: Kees Cook > Cc: Eric Anholt > Cc: Stefan Wahren > Cc: Phil Elwell &g

[RESEND PATCH] dmaengine: bcm2835: Fix cyclic DMA period splitting

in a wrong control block layout and audio issues because the cyclic DMA callback wasn't executing on period boundaries. Fix this by adding the missing total_len update. Signed-off-by: Matthias Reichl <h...@horus.com> Signed-off-by: Martin Sperl <ker...@martin.sperl.org> Tested-by:

[RESEND PATCH] dmaengine: bcm2835: Fix cyclic DMA period splitting

in a wrong control block layout and audio issues because the cyclic DMA callback wasn't executing on period boundaries. Fix this by adding the missing total_len update. Signed-off-by: Matthias Reichl Signed-off-by: Martin Sperl Tested-by: Clive Messer Reviewed-by: Eric Anholt --- drivers/dma

Re: [PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks

On Mon, Jun 13, 2016 at 10:06:49PM -0700, Eric Anholt wrote: > Matthias Reichl <h...@horus.com> writes: > > > The current cyclic DMA period splitting implementation can generate > > very small chunks at the end of each period. For example a 65536 byte > > period w

Re: [PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks

On Mon, Jun 13, 2016 at 10:06:49PM -0700, Eric Anholt wrote: > Matthias Reichl writes: > > > The current cyclic DMA period splitting implementation can generate > > very small chunks at the end of each period. For example a 65536 byte > > period will be split into a 65532

[PATCH 0/2] dmaengine: bcm2835: Cyclic DMA fixes

and fixed by the first patch. The second patch, avoiding very small chunks, is mainly a precaution. While small chunks are not known to have caused any problems so far they have the potentical to cause very hard to track down issues. So better avoid such situations in the first place. Matthias Reichl (2

[PATCH 0/2] dmaengine: bcm2835: Cyclic DMA fixes

and fixed by the first patch. The second patch, avoiding very small chunks, is mainly a precaution. While small chunks are not known to have caused any problems so far they have the potentical to cause very hard to track down issues. So better avoid such situations in the first place. Matthias Reichl (2

[PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks

max_len/2 and max_len*0.75 bytes. Signed-off-by: Matthias Reichl <h...@horus.com> Signed-off-by: Martin Sperl <ker...@martin.sperl.org> Tested-by: Clive Messer <clive.mes...@digitaldreamtime.co.uk> --- drivers/dma/bcm2835-dma.c | 14 ++ 1 file changed, 14 insertions(

[PATCH 2/2] dmaengine: bcm2835: Avoid splitting periods into very small chunks

max_len/2 and max_len*0.75 bytes. Signed-off-by: Matthias Reichl Signed-off-by: Martin Sperl Tested-by: Clive Messer --- drivers/dma/bcm2835-dma.c | 14 ++ 1 file changed, 14 insertions(+) diff --git a/drivers/dma/bcm2835-dma.c b/drivers/dma/bcm2835-dma.c index 344bcf92..36b9

[PATCH 1/2] dmaengine: bcm2835: Fix cyclic DMA period splitting

in a wrong control block layout and audio issues because the cyclic DMA callback wasn't executing on period boundaries. Fix this by adding the missing total_len update. Signed-off-by: Matthias Reichl <h...@horus.com> Signed-off-by: Martin Sperl <ker...@martin.sperl.org> Tested-by:

[PATCH 1/2] dmaengine: bcm2835: Fix cyclic DMA period splitting

in a wrong control block layout and audio issues because the cyclic DMA callback wasn't executing on period boundaries. Fix this by adding the missing total_len update. Signed-off-by: Matthias Reichl Signed-off-by: Martin Sperl Tested-by: Clive Messer --- drivers/dma/bcm2835-dma.c | 5

[PATCH 2/2] ASoC: bcm2835: Add S16_LE support via packed DMA transfers

stereo samples that can be transferred via 32-bit DMA Signed-off-by: Matthias Reichl <h...@horus.com> --- sound/soc/bcm/bcm2835-i2s.c | 9 + 1 file changed, 9 insertions(+) diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c index 1c1f221..40ba01d 100644 --- a/sound/s

[PATCH 2/2] ASoC: bcm2835: Add S16_LE support via packed DMA transfers

stereo samples that can be transferred via 32-bit DMA Signed-off-by: Matthias Reichl --- sound/soc/bcm/bcm2835-i2s.c | 9 + 1 file changed, 9 insertions(+) diff --git a/sound/soc/bcm/bcm2835-i2s.c b/sound/soc/bcm/bcm2835-i2s.c index 1c1f221..40ba01d 100644 --- a/sound/soc/bcm/bcm2835-i2s.c

[PATCH 1/2] ASoC: dmaengine_pcm: Add support for packed transfers

that aren't handled by the ALSA core. Signed-off-by: Matthias Reichl <h...@horus.com> --- include/sound/dmaengine_pcm.h | 12 sound/core/pcm_dmaengine.c| 11 +-- sound/soc/soc-generic-dmaengine-pcm.c | 57 +-- 3 files chang

[PATCH 1/2] ASoC: dmaengine_pcm: Add support for packed transfers

that aren't handled by the ALSA core. Signed-off-by: Matthias Reichl --- include/sound/dmaengine_pcm.h | 12 sound/core/pcm_dmaengine.c| 11 +-- sound/soc/soc-generic-dmaengine-pcm.c | 57 +-- 3 files changed, 55 insertions(+), 25