Re: [PATCH 0/3] Modernize tasklet callback API

On Tue, 11 Aug 2020 23:33:13 +0200, Kees Cook wrote: > > On Mon, Aug 03, 2020 at 02:16:15PM +0530, Allen wrote: > > Here's the series re-based on top of 5.8 > > https://github.com/allenpais/tasklets/tree/V3 > > Great! > > > Let me know how you would want these to be reviewed. > > Was a Coccinel

[PATCH RESEND] staging: vc04_services: Use scnprintf() for avoiding potential buffer overflow

-rpi-ker...@lists.infradead.org Cc: de...@driverdev.osuosl.org Signed-off-by: Takashi Iwai --- Greg, could you apply it if it's OK? I forgot Cc to you and staging ML in the previous thread. drivers/staging/vc04_services/interface/vchiq_arm/vchiq_arm.c | 6 +++--- 1 file changed, 3 insertions(

Re: [PATCH] staging: greybus: Use scnprintf() for avoiding potential buffer overflow

On Wed, 11 Mar 2020 17:40:02 +0100, Johan Hovold wrote: > > On Wed, Mar 11, 2020 at 12:01:26PM +0100, Takashi Iwai wrote: > > On Wed, 11 Mar 2020 11:09:03 +0100, > > Johan Hovold wrote: > > > > > > On Wed, Mar 11, 2020 at 11:02:33AM +0100, Takashi Iwai wrote:

Re: [PATCH] staging: greybus: Use scnprintf() for avoiding potential buffer overflow

On Wed, 11 Mar 2020 11:09:03 +0100, Johan Hovold wrote: > > On Wed, Mar 11, 2020 at 11:02:33AM +0100, Takashi Iwai wrote: > > On Wed, 11 Mar 2020 10:58:14 +0100, > > Johan Hovold wrote: > > > > > > On Wed, Mar 11, 2020 at 10:19:06AM +0100, Takashi Iwai wrote:

[PATCH RESEND] staging: greybus: loopback_test: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai --- Just corrected the subject prefix per request. drivers/staging/greybus/tools

Re: [PATCH] staging: greybus: Use scnprintf() for avoiding potential buffer overflow

On Wed, 11 Mar 2020 10:58:14 +0100, Johan Hovold wrote: > > On Wed, Mar 11, 2020 at 10:19:06AM +0100, Takashi Iwai wrote: > > Since snprintf() returns the would-be-output size instead of the > > actual output size, the succeeding calls may go beyond the given > >

[PATCH 0/3] staging: rtl*: Use scnprintf() for avoiding potential buffer overflow

Hi, here is a series of trivial patches just to convert suspicious snprintf() usages with the more safer one, scnprintf(), just like other few patches I've already sent out. Takashi === Takashi Iwai (3): staging: rtl8188eu: Use scnprintf() for avoiding potential buffer ove

[PATCH 3/3] staging: rtl8723bs: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai --- drivers/staging/rtl8723bs/core/rtw_wlan_util.c | 14 +++--- drivers

[PATCH 2/3] staging: rtl8192e: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai --- drivers/staging/rtl8192e/rtllib_rx.c | 4 ++-- drivers/staging/rtl8192e

[PATCH 1/3] staging: rtl8188eu: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai --- drivers/staging/rtl8188eu/core/rtw_debug.c | 16 drivers

[PATCH] staging: most: core: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai --- drivers/staging/most/core.c | 6 +++--- 1 file changed, 3 insertions(+), 3

[PATCH] staging: greybus: Use scnprintf() for avoiding potential buffer overflow

Since snprintf() returns the would-be-output size instead of the actual output size, the succeeding calls may go beyond the given buffer limit. Fix it by replacing with scnprintf(). Signed-off-by: Takashi Iwai --- drivers/staging/greybus/tools/loopback_test.c | 24 1

[PATCH for-5.6 4/4] staging: bcm2835-audio: Drop superfluous ioctl PCM ops

PCM core deals the empty ioctl field now as default. Let's kill the redundant lines. Signed-off-by: Takashi Iwai --- drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 2 -- 1 file changed, 2 deletions(-) diff --git a/drivers/staging/vc04_services/bcm2835-audio/bcm2835-pcm

[PATCH for-5.6 3/4] staging: most: Drop superfluous ioctl PCM ops

PCM core deals the empty ioctl field now as default. Let's kill the redundant lines. Signed-off-by: Takashi Iwai --- drivers/staging/most/sound/sound.c | 1 - 1 file changed, 1 deletion(-) diff --git a/drivers/staging/most/sound/sound.c b/drivers/staging/most/sound/sound.c index 7c212c0

[PATCH for-5.6 0/4] staging: ALSA PCM API updates

prefer, I can merge them through sound tree, too. Let me know. thanks, Takashi === Takashi Iwai (4): staging: most: Use managed buffer allocation staging: bcm2835-audio: Use managed buffer allocation staging: most: Drop superfluous ioctl PCM ops staging: bcm2835-audio: Drop superfluous

[PATCH for-5.6 2/4] staging: bcm2835-audio: Use managed buffer allocation

Clean up the driver with the new managed buffer allocation API. The hw_params and hw_free callbacks became superfluous and dropped. Signed-off-by: Takashi Iwai --- .../staging/vc04_services/bcm2835-audio/bcm2835-pcm.c | 17 + 1 file changed, 1 insertion(+), 16 deletions

[PATCH for-5.6 1/4] staging: most: Use managed buffer allocation

Clean up the driver with the new managed buffer allocation API. Also remove the unnecessary checks of channels in hw_params callback as this is guaranteed by the hw constraints in anyway. After these cleanups, the hw_params and hw_free callbacks became empty, hence dropped. Signed-off-by: Takashi

[PATCH] staging: most: Convert to the common vmalloc memalloc

page mapping in the default mmap handler Signed-off-by: Takashi Iwai --- Since the prerequisite commits above are found only on for-next branch of sound git tree, please give ACK if the patch is OK; then I'll apply it on top of my branch. Thanks! drivers/staging/most/

Re: [PATCH] staging: bcm2835-audio: double free in init error path

On Mon, 17 Dec 2018 08:08:54 +0100, Dan Carpenter wrote: > > We free instance here and in the caller. It should be only the caller > which handles it. > > Fixes: d7ca3a71545b ("staging: bcm2835-audio: Operate non-atomic PCM ops") > Signed-off-by: Dan Carpenter

Re: [PATCH v2] ARM: staging: bcm2835-audio: interpolate audio delay

On Sun, 11 Nov 2018 19:21:29 +0100, Mike Brady wrote: > > /* hardware definition */ > static const struct snd_pcm_hardware snd_bcm2835_playback_hw = { > .info = (SNDRV_PCM_INFO_INTERLEAVED | SNDRV_PCM_INFO_BLOCK_TRANSFER | >SNDRV_PCM_INFO_MMAP | SNDRV_PCM_INFO_MMAP_VALID |

Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay

On Tue, 06 Nov 2018 22:05:11 +0100, Mike Brady wrote: > > > > On 5 Nov 2018, at 16:11, Takashi Iwai wrote: > > > > On Mon, 05 Nov 2018 16:57:07 +0100, > > Mike Brady wrote: > >> > >>> One another thing I'd like to point out is t

Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay

On Mon, 05 Nov 2018 16:57:07 +0100, Mike Brady wrote: > > > One another thing I'd like to point out is that the value given in the > > patch is nothing but an estimated position, optimistically calculated > > via the system timer. Mike and I had already discussion in another > > thread, and anoth

Re: [alsa-devel] [PATCH v2] staging: bcm2835-audio: interpolate audio delay

On Thu, 25 Oct 2018 00:02:34 +0200, Kirill Marinushkin wrote: > > >> When you play sound - the pointer increments. > > > > Unfortunately, when you play sound, the pointer does not actually > > increment, for up to about 10 milliseconds. I know of no way to actually > > access the true “live” po

Re: [PATCH] staging: bcm2835-audio: interpolate audio delay

On Thu, 18 Oct 2018 12:57:15 +0200, Mike Brady wrote: > > When the BCM2835 audio output is used, userspace sees a jitter up to 10ms > in the audio position, aka "delay" -- the number of frames that must > be output before a new frame would be played. > Make this a bit nicer for userspace by interp

Re: [PATCH] hv/netvsc: Fix NULL dereference at single queue mode fallback

On Tue, 14 Aug 2018 19:29:32 +0200, David Miller wrote: > > From: Takashi Iwai > Date: Tue, 14 Aug 2018 19:10:50 +0200 > > > The recent commit 916c5e1413be ("hv/netvsc: fix handling of fallback > > to single queue mode") tried to fix the fallback behavior

[PATCH] hv/netvsc: Fix NULL dereference at single queue mode fallback

to a NULL dereference at the callers that expect non-NULL value. Fix it by returning the proper net_device object. Fixes: 916c5e1413be ("hv/netvsc: fix handling of fallback to single queue mode") Cc: Signed-off-by: Takashi Iwai --- drivers/net/hyperv/rndis_filter.c | 2 +- 1 file change

Re: [PATCH] media: add GFP flag to media_*() that could get called in atomic context

On Mon, 14 Mar 2016 11:13:58 +0100, Mauro Carvalho Chehab wrote: > > Em Mon, 14 Mar 2016 09:22:37 +0200 > Sakari Ailus escreveu: > > > Hi Shuah, > > > > On Sat, Mar 12, 2016 at 06:48:09PM -0700, Shuah Khan wrote: > > > Add GFP flags to media_create_pad_link(), media_create_intf_link(), > > > me

Re: [RFC][PATCH] x86: remove vmalloc.h from asm/io.h

Cc: Haiyang Zhang > Cc: Hiral Patel > Cc: Suma Ramars > Cc: Brian Uchino > Cc: "James E.J. Bottomley" > Cc: Jaroslav Kysela > Cc: Takashi Iwai For the sound bits, Acked-by: Takashi Iwai thanks, Takashi > Cc: Andrew Morton > Suggested-by: David Miller >

Re: [PATCH 00/25] line6usb cleanup

At Mon, 12 Jan 2015 17:35:01 +0100, Takashi Iwai wrote: > > At Sun, 11 Jan 2015 15:04:55 -0600, > Chris Rorvick wrote: > > > > > At Fri, 9 Jan 2015 23:35:46 -0600, > > > Chris Rorvick wrote: > > >> > > >> I have a TonePort UX2 that I

Re: [PATCH 00/27] staging: line6 patches queued up

At Mon, 12 Jan 2015 12:42:33 -0800, Greg Kroah-Hartman wrote: > > Hi Takashi, > > Here are all of the line6 patches that have been sent to me that were in > my queue, including the series from Chris that caused you to want to > move the driver out of staging. I included it here as it had to be >

Re: [PATCH 00/25] line6usb cleanup

At Mon, 12 Jan 2015 11:52:27 -0800, Greg Kroah-Hartman wrote: > > On Mon, Jan 12, 2015 at 05:35:01PM +0100, Takashi Iwai wrote: > > At Sun, 11 Jan 2015 15:04:55 -0600, > > Chris Rorvick wrote: > > > > > > > At Fri, 9 Jan 2015 23:35:46 -0600, > > >

Re: [PATCH 00/25] line6usb cleanup

At Sun, 11 Jan 2015 15:04:55 -0600, Chris Rorvick wrote: > > > At Fri, 9 Jan 2015 23:35:46 -0600, > > Chris Rorvick wrote: > >> > >> I have a TonePort UX2 that I've used for testing, meaning that some of > >> this is really only compile-tested. > > > > If anyone is responsible for testing with re

Re: [PATCH 00/25] line6usb cleanup

At Fri, 9 Jan 2015 23:35:46 -0600, Chris Rorvick wrote: > > The line6usb driver references the device's idProduct and, in some > cases, the interface number in a number of places to determine device- > specific configuration values and to call device-specific functionality. > Rework code to lever

Re: [PATCH] staging: line6: fix possible overrun

At Mon, 28 Apr 2014 01:44:25 +0300, Dan Carpenter wrote: > > On Sun, Apr 27, 2014 at 10:00:43PM +0200, Mateusz Guzik wrote: > > > > and a WARN_ON + -EINVAL in line6_init_audio to catch future > > > > offenders. > > > > > > Returning -EINVAL is a bad idea because it would break the driver > > >

Re: [PATCH] staging/line6: Fix kzalloc coding style issue

At Mon, 7 Apr 2014 00:12:30 +0200, L. Alberto Giménez wrote: > > Pass the actual variable to sizeof instead of a type definition. > > Signed-off-by: L. Alberto Giménez Acked-by: Takashi Iwai BTW, does anyone work on line6 stuff actively? It's been in staging forever, and

Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers

At Thu, 26 Sep 2013 10:25:13 +0200, Takashi Iwai wrote: > > At Thu, 26 Sep 2013 08:54:25 +0100, > Russell King - ARM Linux wrote: > > > > On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote: > > > Hi, > > > > > > sorry for the lat re

Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers

At Thu, 26 Sep 2013 08:54:25 +0100, Russell King - ARM Linux wrote: > > On Thu, Sep 26, 2013 at 09:51:23AM +0200, Takashi Iwai wrote: > > Hi, > > > > sorry for the lat response, as I've been traveling in the last weeks. > > > > At Thu, 19 Sep 20

Re: [PATCH 28/51] DMA-API: sound: fix dma mask handling in a lot of drivers

Hi, sorry for the lat response, as I've been traveling in the last weeks. At Thu, 19 Sep 2013 22:53:02 +0100, Russell King wrote: > > This code sequence is unsafe in modules: > > static u64 mask = DMA_BIT_MASK(something); > ... > if (!dev->dma_mask) > dev->dma_mask = &mask;