On 29/08/2025 10.49, Jinchao Wang wrote:
> Make module signature rejection messages more visible by using pr_err
> instead of pr_notice.
Can you elaborate a bit more? Why is this needed?
IMO, I don't think making it more visible is enough rational to increase the
level.
On 29/08/2025 10.49, Jinchao Wang wrote:
> Include reason in error message when force loading is disabled.
>
> Signed-off-by: Jinchao Wang
> ---
> kernel/module/main.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index c66b26184936..e748
On 24/08/2025 08.49, Daniel Gomez wrote:
> This includes a fix as part of the KSPP (Kernel Self Protection Project) to
> replace the deprecated and unsafe strcpy() calls in the kernel parameter
> string
> handler and sysfs parameters for built-in modules. Single commit, no
The following changes since commit 8f5ae30d69d7543eee0d70083daf4de8fe15d585:
Linux 6.17-rc1 (2025-08-10 19:41:16 +0300)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git
tags/modules-6.17-rc3.fixes
for you to fetch changes up to 5eb4b9a
copystring);
>> @@ -841,7 +842,7 @@ static void __init param_sysfs_builtin(void)
>> dot = strchr(kp->name, '.');
>> if (!dot) {
>> /* This happens for core_param() */
>> -strcpy(modname, "kernel");
>> +strscpy(modname, "kernel");
>> name_len = 0;
>> } else {
>> name_len = dot - kp->name + 1;
>
> Reviewed-by: Petr Pavlu
>
Reviewed-by: Daniel Gomez
The following changes since commit 260f6f4fda93c8485c8037865c941b42b9cba5d2:
Merge tag 'drm-next-2025-07-30' of https://gitlab.freedesktop.org/drm/kernel
(2025-07-30 19:26:49 -0700)
are available in the Git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/modules/linux.git/
tag
prefix length check
commit: bdc877ba6b7ff1b6d2ebeff11e63da4a50a54854
[4/5] tracing: Replace MAX_PARAM_PREFIX_LEN with MODULE_NAME_LEN
commit: a7c54b2b41dd1f6ec780e7fbfb13f70c64c9731d
[5/5] module: Rename MAX_PARAM_PREFIX_LEN to __MODULE_NAME_LEN
commit: 40a826bd6c82ae45cfd3a19cd2a60a10f56b74c0
Best regards,
--
Daniel Gomez
> + static_assert(sizeof(""prefix) - 1 <= __MODULE_NAME_LEN); \
> static const char __param_str_##name[] = prefix #name; \
> static struct kernel_param __moduleparam_const __param_##name \
> __used __section("__param") \
LGTM,
Reviewed-by: Daniel Gomez
t char this_mod[] = "__this_module";
> - char modname[MAX_PARAM_PREFIX_LEN + sizeof(this_mod) + 2];
> + char modname[MODULE_NAME_LEN + sizeof(this_mod) + 2];
> unsigned long val;
> int n;
>
LGTM,
Reviewed-by: Daniel Gomez
On 21/07/2025 11.21, Petr Pavlu wrote:
> On 7/17/25 9:23 PM, Daniel Gomez wrote:
>> On 30/06/2025 16.32, Petr Pavlu wrote:
>>> The moduleparam code allows modules to provide their own definition of
>>> MODULE_PARAM_PREFIX, instead of using the default KBUILD_
On 30/06/2025 16.32, Petr Pavlu wrote:
> The moduleparam code allows modules to provide their own definition of
> MODULE_PARAM_PREFIX, instead of using the default KBUILD_MODNAME ".".
>
> Commit 730b69d22525 ("module: check kernel param length at compile time,
> not runtime") added a check to ensu
static struct {
> - char name[MODULE_NAME_LEN + 1];
> + char name[MODULE_NAME_LEN];
> char taints[MODULE_FLAGS_BUF_SIZE];
> } last_unloaded_module;
>
LGTM,
Reviewed-by: Daniel Gomez
new code not only returns the correct errors
indicated in delete_module(2) but also checks for the case user passes an
empty string and the case where NUL char is not found when copying (with len
== MODULE_NAME_LEN) as well as it's using the correct length (MODULE_NAME_LEN)
for copying.
Reviewed-by: Daniel Gomez
On 11/07/2025 15.51, Thomas WeiÃschuh wrote:
> On Fri, Jul 11, 2025 at 03:39:04PM +0200, Daniel Gomez wrote:
>>
>> On Fri, 11 Jul 2025 15:31:35 +0200, Thomas Weißschuh wrote:
>>> Code using IS_ENABLED(CONFIG_MODULES) as a C expression may need access
>>> to th
4d878577e2b8c46ed7b6be5f5459
[2/3] module: make structure definitions always visible
commit: 02281b559cd1fdfdc8f7eb05bbbe3ab7b35246f0
[3/3] kunit: test: Drop CONFIG_MODULE ifdeffery
commit: dffcba8acea3a80b3478750ac32f17bd5345b68e
Best regards,
--
Daniel Gomez
r errors can be detected faster.
>
> Signed-off-by: Thomas Weißschuh
Reviewed-by: Daniel Gomez
On 11/07/2025 08.29, Thomas WeiÃschuh wrote:
> On Mon, Jul 07, 2025 at 09:11:05PM +0200, Daniel Gomez wrote:
>> On 12/06/2025 16.53, Thomas WeiÃschuh wrote:
>>> To write code that works with both CONFIG_MODULES=y and CONFIG_MODULES=n
>>> it is convenient to use &qu
On 08/07/2025 22.21, Linus Torvalds wrote:
> On Tue, 8 Jul 2025 at 12:38, Daniel Gomez wrote:
>>
>> Petr and Sebastian went down to the archive history (before Git) and
>> found the commit that broke it b3b91325f3c7 ("Don't relocate
>> non-allocated region
6-rc1)
and another introduced back in v6.4-rc1. Both have been in linux-next since
next-250701 and have passed the modules ci tests using kdevops. Finally, as Petr
and Luis mentioned in previous pull requests, add myself (Daniel Gomez) to the
list of modules maintainers.
The first was reported by In
On 12/06/2025 16.53, Thomas WeiÃschuh wrote:
> To write code that works with both CONFIG_MODULES=y and CONFIG_MODULES=n
> it is convenient to use "if (IS_ENABLED(CONFIG_MODULES))" over raw #ifdef.
> The code will still fully typechecked but the unreachable parts are
> discarded by the compiler. Thi
On Fri, 04 Jul 2025 21:39:59 +0200, Daniel Gomez wrote:
> Update Daniel Gomez's modules reviewer role to maintainer. This is
> according to the plan [1][2] of scaling with more reviewers for modules
> (for the incoming Rust support [3]) and rotate [4] every 6 months.
>
&g
From: Daniel Gomez
Update Daniel Gomez's modules reviewer role to maintainer. This is
according to the plan [1][2] of scaling with more reviewers for modules
(for the incoming Rust support [3]) and rotate [4] every 6 months.
[1] Link:
https://lore.kernel.org/linux-modules/
zspanzx4
From: Daniel Gomez
On Wed, 18 Jun 2025 14:26:25 +0200, Petr Pavlu wrote:
> The first patch is an actual fix. The second patch is a minor related
> cleanup.
>
> Changes since v1 [1]:
> - Initialize t to MOD_MEM_NUM_TYPES in move_module(), instead of assigning
> the value la
On 18/06/2025 14.26, Petr Pavlu wrote:
> The function move_module() uses the variable t to track how many memory
> types it has allocated and consequently how many should be freed if an
> error occurs.
>
> The variable is initially set to 0 and is updated when a call to
> module_memory_alloc() fai
ymore, so the structure can be made internal.
>
> Signed-off-by: Thomas Weißschuh
Reviewed-by: Daniel Gomez
,7 +2776,7 @@ static int move_module(struct module *mod, struct
> load_info *info)
> return 0;
> out_err:
> module_memory_restore_rox(mod);
> - for (t--; t >= 0; t--)
> + while (t--)
> module_memory_free(mod, t);
> if (codetag_section_found)
> codetag_free_module_sections(mod);
Reviewed-by: Daniel Gomez
NUM_TYPES;
> - int ret = -ENOMEM;
> bool codetag_section_found = false;
>
> for_each_mod_mem_type(type) {
Reviewed-by: Daniel Gomez
>> One thing though, we are "releasing" the memory even if we have skipped the
>> allocation in the first place. So, I think it would make sense to release
>> only
>> for the types we have actually allocated. What do you think?
>
> I noticed this too, specifically because move_module() is inco
> Do you mean the following, or something else:
>
> static int move_module(struct module *mod, struct load_info *info)
> {
> int i;
> enum mod_mem_type t = MOD_MEM_NUM_TYPES;
> int ret;
> bool codetag_section_found = false;
>
> for_each_mod_mem_type(type) {
>
> This seems to be off by one. For instance, if the loop reaches the last
> valid type in mod_mem_type, MOD_INIT_RODATA, and successfully allocates
> its memory, the variable t gets set to MOD_INIT_RODATA. Subsequently, if
> an error occurs later in move_module() and control is transferred to
> out
ed-off-by: Petr Pavlu
Reviewed-by: Daniel Gomez
> ---
> kernel/module/main.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/kernel/module/main.c b/kernel/module/main.c
> index 322b38c0a782..06511607075c 100644
> --- a/kernel/module/main.c
> +++ b/kernel
On 07/06/2025 18.16, Petr Pavlu wrote:
> The function move_module() uses the variable t to track how many memory
> types it has allocated and consequently how many should be freed if an
> error occurs.
>
> The variable is initially set to 0 and is updated when a call to
> module_memory_alloc() fai
On Thu, Mar 06, 2025 at 11:36:55AM +0100, Petr Pavlu wrote:
> In the unlikely case that setting ro_after_init data to read-only fails, it
> is too late to cancel loading of the module. The loader then issues only
> a warning about the situation. Given that this reduces the kernel's
> protection, it
: 0||
1024 -> 2047 : 10748||
Tested-by: Daniel Gomez
Andreas, Petr, Miguel,
Based on the discussion in v7, it seems that all these patches will go through
the Rust tree. Is that correct? What would be missing from t
-862b-fd77552ae...@suse.com/ [1]
> Signed-off-by: Andreas Hindborg
And this is what we signed up for here:
https://lore.kernel.org/all/zspanzx4-5dro...@bombadil.infradead.org/
Acked-by: Daniel Gomez
> ---
> MAINTAINERS | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/
On Mon, Jan 06, 2025 at 04:13:29PM -0800, Kees Cook wrote:
> On Fri, Jan 03, 2025 at 05:13:32PM +0100, Petr Pavlu wrote:
> > On 12/5/24 20:46, Christophe Leroy wrote:
> > > This series reworks module loading to avoid leaving the module in a
> > > stale state when protecting ro_after_init section fa
On 12/4/2024 4:14 PM, Petr Pavlu wrote:
On 11/28/24 21:23, Daniel Gomez wrote:
On 11/12/2024 3:35 PM, Petr Pavlu wrote:
On 11/12/24 10:43, Daniel Gomez wrote:
On Mon Nov 11, 2024 at 7:53 PM CET, Christophe Leroy wrote:
Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
On Sat Nov 9, 2024 at 11
On 11/21/2024 9:42 PM, Sami Tolvanen wrote:
Add a basic DWARF parser, which uses libdw to traverse the debugging
information in an object file and looks for functions and variables.
In follow-up patches, this will be expanded to produce symbol versions
for CONFIG_MODVERSIONS from DWARF.
Signed-o
On 11/12/2024 3:35 PM, Petr Pavlu wrote:
On 11/12/24 10:43, Daniel Gomez wrote:
On Mon Nov 11, 2024 at 7:53 PM CET, Christophe Leroy wrote:
Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
Once module init has succeded it is too late
On Sat Nov 16, 2024 at 6:20 PM CET, Uwe Kleine-König wrote:
> On Sat, Nov 16, 2024 at 09:15:55AM +0100, Daniel Gomez wrote:
>> On Fri Nov 15, 2024 at 7:50 PM CET, Werner Sembach wrote:
>> > From: Uwe Kleine-König
>> >
>> > TUXEDO has not yet relicensed a modu
On Fri Nov 15, 2024 at 7:50 PM CET, Werner Sembach wrote:
> From: Uwe Kleine-König
>
> TUXEDO has not yet relicensed a module for GPLv2+ as a reply from former
> contributers the committed code under GPLv3+ is awaited.
FYI, the SPDX identifier GPL-2.0+ is deprecated as of 2.0rc2 [1]. I think you'
On Thu Nov 14, 2024 at 11:31 AM CET, Uwe Kleine-König wrote:
> Tuxedo licenses the modules used on their hardware under GPLv3+, to
> "keep control of the upstream pacing" – and want to re-license the code
> while upstreaming.
>
> They were asked to then at least not use MODULE_LICENSE("GPL") which
On Thu Nov 14, 2024 at 11:31 AM CET, Uwe Kleine-König wrote:
> Hello,
>
> the kernel modules provided by Tuxedo on
> https://protect2.fireeye.com/v1/url?k=2f239e82-70bfb7a8-2f2215cd-000babe598f7-32952349600b722d&q=1&e=9535a8fa-5a9d-4d94-a12d-ff39b9d3b9cf&u=https%3A%2F%2Fgitlab.com%2Ftuxedocomputers
On Mon Nov 11, 2024 at 7:53 PM CET, Christophe Leroy wrote:
>
>
> Le 09/11/2024 à 23:17, Daniel Gomez a écrit :
>> On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
>>> Once module init has succeded it is too late to cancel loading.
>>> If setting ro_aft
t section needs to be
> set to read-only, no need to re-apply it to already set rodata.
>
> Split module_enable_rodata_ro() in two.
>
> Signed-off-by: Christophe Leroy
Tested-by: Daniel Gomez
> ---
> kernel/module/internal.h | 3 ++-
> kernel/module/main.c | 4
On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
> Once module init has succeded it is too late to cancel loading.
> If setting ro_after_init data section to read-only fails, all we
> can do is to inform the user through a warning.
>
> Reported-by: Thomas Gleixner
> Closes:
> https://l
On Sat Nov 9, 2024 at 11:35 AM CET, Christophe Leroy wrote:
> To be on the safe side, try to set ro_after_init data section readonly
> at the same time as rodata. If it fails it will likely fail again
> later so let's cancel module loading while we still can do it.
> If it doesn't fail, put it back
On Fri Nov 8, 2024 at 5:09 PM CET, Daniel Gomez wrote:
> On Fri Nov 8, 2024 at 4:49 PM CET, Luis Chamberlain wrote:
>> + Other new module maintainers
>>
>> On Fri, Nov 08, 2024 at 09:12:03AM +0100, Christophe Leroy wrote:
>>> Hi Luis,
>>>
>>&
From: Daniel Gomez
When ro_after_init fails, we need to unload the module.
Rename the goto tag to fail_ro_after_init to make it more clear and try
to check for dependencies, stop the module and call the exit function.
This allows to unload the module if ro_after_init fails.
This fixes the
From: Daniel Gomez
Ensure the module state change and reference drop operations are
performed within module_mutex to prevent potential race conditions in
the failure path.
Signed-off-by: Daniel Gomez
---
kernel/module/main.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git
From: Daniel Gomez
Ensure the module reference is only dropped once in case we fail at
MOD_RO_AFTER_INIT case.
Signed-off-by: Daniel Gomez
---
kernel/module/main.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/kernel/module/main.c b/kernel/module/main.c
index
pping(bdev);
>679< if (bdev->bd_disk->fops->release)
680bdev->bd_disk->fops->release(bdev->bd_disk);
681}
682
683static int blkdev_get_whole(struct block_device *bdev, blk_mode_t mode)
684{
To: Luis Chamberlain
To: Petr
From: Daniel Gomez
The module_deallocate() function no longer requires the struct load_info
parameter as of commit 48fd11880b5ef04270be8a87d9a9a9ee2fdae338 ("module:
Fix performance regression on modules with large symbol tables"). This
commit removes the now-unused parameter.
No
ode
> to address this seems complex. right ?
I have a RFC ready with this, I'll send this now so we can discuss on
with a proposal.
>
>
>> Especially when the module has no exit() path or when
>> CONFIG_MODULE_UNLOAD is not built in.
>
> That's exactly the othe
On 9/24/2024 11:19 PM, Matthew Maurer wrote:
`validate_section_offset` doesn't modify the info passed in. Make this
clear by adjusting the type signature.
Signed-off-by: Matthew Maurer
---
kernel/module/main.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/kernel/module/
Rust and C code for modules so we can ensure we get proper
> reviews for both parts of the code and so that we can scale.
>
> Add those who have stepped up to help.
>
> Signed-off-by: Luis Chamberlain
> ---
Acked-by: Daniel Gomez
Daniel
>
> First order of busine
On Wed, Jul 24, 2024 at 05:04:25PM GMT, Sami Tolvanen wrote:
> Hi Luis,
>
> On Thu, Jul 18, 2024 at 5:15 PM Luis Chamberlain wrote:
> >
> > On Tue, Jul 09, 2024 at 12:08:16PM +0200, Miguel Ojeda wrote:
> > > On Mon, Jul 8, 2024 at 11:42 PM Luis Chamberlain
> > > wrote:
> > > >
> > > > The ratio
On Tue, 6 Apr 2021 at 22:56, Alex Deucher wrote:
>
> On Mon, Mar 22, 2021 at 6:34 AM Christian König
> wrote:
> >
> > Hi Daniel,
> >
> > Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling
> > > wro
On Fri, 26 Mar 2021 at 13:28, Andy Shevchenko
wrote:
>
> On Fri, Mar 26, 2021 at 11:35:08AM +0100, Daniel Gomez wrote:
> > On Thu, 25 Mar 2021 at 16:43, Andy Shevchenko
> > wrote:
> > > On Thu, Mar 25, 2021 at 04:12:48PM +0100, Daniel Gomez wrote:
>
> ...
>
&g
Hi Andy,
On Thu, 25 Mar 2021 at 16:43, Andy Shevchenko
wrote:
>
> On Thu, Mar 25, 2021 at 04:12:48PM +0100, Daniel Gomez wrote:
> > Add i2c hw base address in the adapter name and when the device is
> > probed.
>
> Why?
> We have /proc/iomem for that.
The initial
root@qt5222:~# i2cdetect -l | grep -i desig
i2c-1 i2c Synopsys DesignWare I2C adapter at 0xfedc5000
I2C adapter
i2c-0 i2c Synopsys DesignWare I2C adapter at 0xfedc4000
I2C adapter
Signed-off-by: Daniel Gomez
---
Hi,
We think it might be interesting to add the physical
On Mon, 22 Mar 2021 at 11:34, Christian König
wrote:
>
> Hi Daniel,
>
> Am 22.03.21 um 10:38 schrieb Daniel Gomez:
> > On Fri, 19 Mar 2021 at 21:29, Felix Kuehling wrote:
> >> This caused a regression in kfdtest in a large-buffer stress test after
> >> me
gt;sg_table) {
if (gtt->user_ptr) ...
}
If you agree, I'll send a v2 patch. Otherwise, maybe we could return
within amdgpu_ttm_tt_unpin_userptr if memory hasn't been allocated.
Any other ideas?
Regards,
Daniel
>
> Reverting this patch fixes the problem for me.
>
&g
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/radeon/radeon_ttm.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_ttm.c
b/drivers/gpu/drm/radeon/radeon_ttm.c
index
On Thu, 18 Mar 2021 at 08:49, Christian König wrote:
>
> Am 17.03.21 um 17:08 schrieb Daniel Gomez:
> > If userptr pages have been pinned but not bounded,
> > they remain uncleared.
> >
> > Signed-off-by: Daniel Gomez
>
> Good catch, not sure if that can eve
If userptr pages have been pinned but not bounded,
they remain uncleared.
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_ttm.c
b/drivers/gpu/drm/amd/amdgpu
On Thu, 11 Mar 2021 at 17:10, Alex Deucher wrote:
>
> On Thu, Mar 11, 2021 at 10:02 AM Alexandre Desnoyers wrote:
> >
> > On Thu, Mar 11, 2021 at 2:49 PM Daniel Gomez wrote:
> > >
> > > On Thu, 11 Mar 2021 at 10:09, Daniel Gomez wrote:
> > > >
&g
On Thu, 11 Mar 2021 at 10:09, Daniel Gomez wrote:
>
> On Wed, 10 Mar 2021 at 18:06, Alex Deucher wrote:
> >
> > On Wed, Mar 10, 2021 at 11:37 AM Daniel Gomez wrote:
> > >
> > > Disabling GFXOFF via the quirk list fixes a hardware lockup in
> > &g
On Wed, 10 Mar 2021 at 18:06, Alex Deucher wrote:
>
> On Wed, Mar 10, 2021 at 11:37 AM Daniel Gomez wrote:
> >
> > Disabling GFXOFF via the quirk list fixes a hardware lockup in
> > Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
> >
> > Signed-off-by: Daniel Go
Disabling GFXOFF via the quirk list fixes a hardware lockup in
Ryzen V1605B, RAVEN 0x1002:0x15DD rev 0x83.
Signed-off-by: Daniel Gomez
---
This patch is a continuation of the work here:
https://lkml.org/lkml/2021/2/3/122 where a hardware lockup was discussed and
a dma_fence deadlock was provoke
n though it is not used in that stack.
Anyway, I'll keep you guys posted with this change.
>
> Regards,
> Christian.
>
> Am 03.02.21 um 09:33 schrieb Daniel Gomez:
> > Hi all,
> >
> > I have a deadlock with the amdgpu mainline driver when running in paralle
On Wed, 3 Feb 2021 at 10:47, Daniel Gomez wrote:
>
> On Wed, 3 Feb 2021 at 10:17, Daniel Vetter wrote:
> >
> > On Wed, Feb 3, 2021 at 9:51 AM Christian König
> > wrote:
> > >
> > > Am 03.02.21 um 09:48 schrieb Daniel Vetter:
> > &g
t; Yeah, that's still a good idea to have.
Here the full backtrace dmesg logs after the hang:
https://pastebin.com/raw/kzivm2L3
This is another dmesg log with the backtraces after SIGKILL the matrix process:
(I didn't have the sysrq enable at the time):
https://pastebin.com/raw/pRBwGcj1
the 'latest' linux-firmware adds support for the
20.45 version but
I haven't tested it yet since I couldn't bring it up properly the
support as I was doing for
the previous versions. Somehow the libamdocl64.so got reduced from 80 Mb to
1.2 Mb and I couldn't figure out
Hi all,
I have a deadlock with the amdgpu mainline driver when running in parallel two
OpenCL applications. So far, we've been able to replicate it easily by executing
clinfo and MatrixMultiplication (from AMD opencl-samples). It's quite old the
opencl-samples so, if you have any other suggestion
0xe10): undefined reference to
`drm_atomic_helper_connector_destroy_state'
Signed-off-by: Daniel Gomez
---
drivers/gpu/drm/rcar-du/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/gpu/drm/rcar-du/Kconfig b/drivers/gpu/drm/rcar-du/Kconfig
index 0919f1f159a4..f65d1489dc50 100644
--- a/drivers/gpu/drm/rcar-du
Hi all,
We are developing a v4l2 subdevice driver to be able to support the imx378
sensor and upstream it. But we would like to have a continuous frame
interval and the
current VIDIOC_SUBDEV_ENUM_FRAME_INTERVAL ioctl implementation doesn't
support it.
How can we proceed here? Can we maybe add the
Stop video streaming when requested.
When s_stream is called to stop the video streaming, if/else condition calls
start_streaming function instead of the one for stopping it.
Fixes: 436190596241 ("media: imx214: Add imx214 camera sensor driver")
Signed-off-by: Daniel Gomez
---
Yo
: of:N*T*Ccirrus,cs47l35
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/mfd/madera-core.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/madera-core.c b/drivers/mfd/madera-core.c
index 2a77988..826b971 100644
--- a/drivers/mfd/madera-core.c
+++ b
Signed-off-by: Daniel Gomez
---
drivers/iio/temperature/maxim_thermocouple.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/iio/temperature/maxim_thermocouple.c
b/drivers/iio/temperature/maxim_thermocouple.c
index c31b963..c613a64 100644
--- a/drivers/iio/temperature
alias: of:N*T*Cadi,ad5758C*
alias: of:N*T*Cadi,ad5758
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/iio/dac/ad5758.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iio/dac/ad5758.c b/drivers/iio/dac/ad5758.c
index 2bdf1b0
: of:N*T*Cadi,adxl372C*
alias: of:N*T*Cadi,adxl372
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/iio/accel/adxl372_spi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iio/accel/adxl372_spi.c b/drivers/iio/accel/adxl372_spi.c
index
: spi:kxsd9
alias: of:N*T*Ckionix,kxsd9C*
alias: of:N*T*Ckionix,kxsd9
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/iio/accel/kxsd9-spi.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/drivers/iio/accel/kxsd9-spi.c b/drivers/iio/accel
*
alias: of:N*T*Cti,tps65912
alias: spi:tps65912
Reported-by: Javier Martinez Canillas
Signed-off-by: Daniel Gomez
---
drivers/mfd/tps65912-spi.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/mfd/tps65912-spi.c b/drivers/mfd/tps65912-spi.c
index 3bd7506..f78be03
84 matches
Mail list logo
