linux-kernel - Re: [PATCH v15 00/16] Add audio support in v4l2 framework

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <394d35bd-f58d-4b13-8790-4d7db2f7d14e@perex.cz>
Date: Tue, 30 Apr 2024 17:03:28 +0200
From: Jaroslav Kysela <perex@...ex.cz>
To: Mark Brown <broonie@...nel.org>,
 Sebastian Fricke <sebastian.fricke@...labora.com>
Cc: Shengjiu Wang <shengjiu.wang@....com>, hverkuil@...all.nl,
 sakari.ailus@....fi, tfiga@...omium.org, m.szyprowski@...sung.com,
 mchehab@...nel.org, linux-media@...r.kernel.org,
 linux-kernel@...r.kernel.org, shengjiu.wang@...il.com, Xiubo.Lee@...il.com,
 festevam@...il.com, nicoleotsuka@...il.com, lgirdwood@...il.com,
 tiwai@...e.com, alsa-devel@...a-project.org, linuxppc-dev@...ts.ozlabs.org
Subject: Re: [PATCH v15 00/16] Add audio support in v4l2 framework

On 30. 04. 24 16:46, Mark Brown wrote:

>> So instead of hammering a driver into the wrong destination, I would
>> suggest bundling our forces and implementing a general memory-to-memory
>> framework that both the media and the audio subsystem can use, that
>> addresses the current shortcomings of the implementation and allows you
>> to upload the driver where it is supposed to be.
> 
> That doesn't sound like an immediate solution to maintainer overload
> issues...  if something like this is going to happen the DRM solution
> does seem more general but I'm not sure the amount of stop energy is
> proportionate.

The "do what you want" ALSA's hwdep device / interface can be used to transfer 
data in/out from SRC using custom read/write/ioctl/mmap syscalls. The question 
is, if the changes cannot be more simpler for the first implementation keeping 
the hardware enumeration in one subsystem where is the driver code placed. I 
also see the benefit to reuse the already existing framework (but is v4l2 the 
right one?).

					Jaroslav

-- 
Jaroslav Kysela <perex@...ex.cz>
Linux Sound Maintainer; ALSA Project; Red Hat, Inc.