ock-pi-4,
> >> qemu-arm64 and qemu-x86_64
> >>- selftests mm gup_longterm fails
> >>
> >> Regression Analysis:
> >> - New regression? Yes
> >> - Reproducibility? Yes
> >>
> >> Test regression: selftests mm gup_longterm error w
while loading shared
libraries liburing.so.2 cannot open shared object file No such file or
directory
>> Test regression: selftests mm cow error while loading shared
libraries>> liburing.so.2 cannot open shared object file No such file or
directory
These do not really look like kernel
n
> is clang nightly.
>
> Regressions found on Dragonboard-845c, Dragonboard-410c, rock-pi-4,
> qemu-arm64 and qemu-x86_64
> - selftests mm gup_longterm fails
>
> Regression Analysis:
> - New regression? Yes
> - Reproducibility? Yes
>
> Test regression:
, Dragonboard-410c, rock-pi-4,
qemu-arm64 and qemu-x86_64
- selftests mm gup_longterm fails
Regression Analysis:
- New regression? Yes
- Reproducibility? Yes
Test regression: selftests mm gup_longterm error while loading shared
libraries liburing.so.2 cannot open shared object file No such file or
On 1/24/2025 11:30 PM, Jeff Johnson wrote:
> On 1/7/25 02:16, Gokul Sriram Palanisamy wrote:
>> This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
>>
>> - Secure PIL is signed, split firmware images which only TrustZone (TZ)
>> can authenticate and load. Linux kernel will s
doing refcounting
> > > > based on FDs, so see if you can use that.
> > > >
> >
> > I can understand that. That said, I think if there's no logic across
> > objects, and bpf_object access is not thread-safe, it puts us into a
> > tough situatio
of coherence in libbpf, so I don't see us
> > > > refcounting maps between bpf_objects. Kernel is doing refcounting
> > > > based on FDs, so see if you can use that.
> > > >
> >
> > I can understand that. That said, I think if there's no logic acro
ing maps between bpf_objects. Kernel is doing refcounting
> > > based on FDs, so see if you can use that.
> > >
>
> I can understand that. That said, I think if there's no logic across
> objects, and bpf_object access is not thread-safe, it puts us into a
> tough s
here's no logic across
objects, and bpf_object access is not thread-safe, it puts us into a
tough situation:
- Complex refcounting, code scanning, etc to keep consistency when
manipulating maps used by multiple programs.
- Parallel loading not being well-balanced, if we split programs acr
way to share BTF data across the objects.
> Having a single BPF object avoids this issue. Potentially, libbpf could
> cache some BTF data to make lessen the impact.
>
> > > > > Alternatively, we can look at this problem as needing libbpf to
> > > > > > >
se bpf_object__load_vmlinux_btf will be called for each object,
and there's currently no way to share BTF data across the objects.
Having a single BPF object avoids this issue. Potentially, libbpf could
cache some BTF data to make lessen the impact.
> > > > Alternatively, we can look
ded can be loaded and
> > > > > attached independently after the initial bpf_object loading and
> > > > > attaching.
> > > > >
> > > > > These programs can also be reloaded and reattached multiple
> > > > > times,
> > &g
On Fri, 2025-01-24 at 10:31 -0800, Andrii Nakryiko wrote:
> > On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
> > wrote:
> > > >
> > > > BPF programs designated as dynamically loaded can be loaded and
> > > > attached independently after the
On Wed, Jan 22, 2025 at 1:53 PM Slava Imameev
wrote:
>
> BPF programs designated as dynamically loaded can be loaded and
> attached independently after the initial bpf_object loading and
> attaching.
>
> These programs can also be reloaded and reattached multiple times,
> e
On 1/7/25 02:16, Gokul Sriram Palanisamy wrote:
> This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
>
> - Secure PIL is signed, split firmware images which only TrustZone (TZ)
> can authenticate and load. Linux kernel will send a request to TZ to
> authenticate and load
BPF programs designated as dynamically loaded can be loaded and
attached independently after the initial bpf_object loading and
attaching.
These programs can also be reloaded and reattached multiple times,
enabling more flexible management of a resident BPF program set.
A key motivation for this
On Thu, 16 Jan 2025, Jan Beulich wrote:
> >> When you say "broken", can you please explain what it is that is _broken_?
> >> Things have changed, yes, but the produced ELF is - afaict - still within
> >> spec. The "partial fix" as you call it wasn't really a fix, but a band-aid
> >> for some broke
On 16.01.2025 16:29, Mikulas Patocka wrote:
>
>
> On Thu, 16 Jan 2025, Jan Beulich wrote:
>
>> On 15.01.2025 19:02, Mikulas Patocka wrote:
>>> On Tue, 14 Jan 2025, Sami Tolvanen wrote:
On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka
wrote:
> On PA-RISC, with the kernel 6.12.9, I
On Thu, 16 Jan 2025, Jan Beulich wrote:
> On 15.01.2025 19:02, Mikulas Patocka wrote:
> > On Tue, 14 Jan 2025, Sami Tolvanen wrote:
> >> On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka
> >> wrote:
> >>> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
> >>> a module is
explain what it is that is _broken_?
Things have changed, yes, but the produced ELF is - afaict - still within
spec. The "partial fix" as you call it wasn't really a fix, but a band-aid
for some broken consumers of ELF. Plus modpost, being one such example,
was supposedly corrected a
5c50 2**4
>
> Sami
Hi
I use version "GNU ld (GNU Binutils for Debian) 2.43.50.20250108".
It was broken in the commit 1f1b5e506bf0d9bffef8525eb9bee19646713eb6 in
the binutils-gdb git and partially fixed in the commit
d41df13ab36b224a622c0bdf28a96a0dee79db77 - the section is still not
aligned at their s
Hi Mikulas,
On Tue, Jan 14, 2025 at 6:07 PM Mikulas Patocka wrote:
>
> Hi
>
> On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
> a module is loaded. The warnings are caused by the fact that the
> .gnu.linkonce.this_module section is not aligned to the appropriate
> bounda
Hi
On PA-RISC, with the kernel 6.12.9, I get unaligned pointer warnings when
a module is loaded. The warnings are caused by the fact that the
.gnu.linkonce.this_module section is not aligned to the appropriate
boundary. If I dump the module content with "objdump -h configs.ko", I get
this. Not
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 prote
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 prote
This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
- Secure PIL is signed, split firmware images which only TrustZone (TZ)
can authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to t
This series depends on Sricharan's tmel-qmp mailbox driver series v2 [1].
- Secure PIL is signed, split firmware images which only TrustZone (TZ)
can authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to t
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 fails.
> >
> > Once module init has
On 1/4/25 08:39, Christophe Leroy wrote:
> Le 03/01/2025 à 17:13, Petr Pavlu a écrit :
>> 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 fails.
&
Le 03/01/2025 à 16:40, Petr Pavlu a écrit :
On 12/10/24 11:49, Daniel Gomez wrote:>>> Do you envision that the userspace would handle this problem
differently
and it is worth adding the complexity?
What complexity do you mean?
The complexity that I was referring to here is mainly the ear
Le 03/01/2025 à 17:13, Petr Pavlu a écrit :
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 fails.
Once module init has succeded it is too late to cancel loading.
If setting
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 fails.
>
> Once module init has succeded it is too late to cancel loading.
> If setting ro_after_init data section to
, 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 i
On Thu, Dec 05, 2024 at 08:46:14PM +0100, Christophe Leroy wrote:
> This series reworks module loading to avoid leaving the module in a
> stale state when protecting ro_after_init section fails.
>
> Once module init has succeded it is too late to cancel loading.
> If setting ro_
: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://protect2.fireeye.com/v1/url?k=d3deb284
This series reworks module loading to avoid leaving the module in a
stale state when protecting ro_after_init section fails.
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
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://lore.kernel.org/all/20230915082126.4187913-1-ruanjin...@huawei.com/
Fixes
mez 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_after_init data section to read-only fails, all we
>>>>>> can do i
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://protect2.fireeye.com/v1/url?k=d3deb284-b2a35ac3-d3df39cb-74fe485fff30-288375d7d91e4ad9&q=1&e=701066ca-634d-4
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
Le 12/11/2024 à 10:43, Daniel Gomez a écrit :
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
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
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_after_init data section to read-only fails, all we
can do is to inform the user through a warning.
Reported
On 11/9/24 11:35, 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.
Makes sense to me. If I'm looking correctly, set_mem
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
>
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://lore.kernel.org/all/20230915082126.4187913-1-ruanjin...@huawei.com/
Fixes
On Wed, Sep 11, 2024 at 11:28:02AM +0800, Chunhui Li wrote:
> When insmod a kernel module, if fails in add_notes_attrs or
> add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
> will still return success, but we can't access user interface
> on android device.
>
> Patch for make mod_sy
When insmod a kernel module, if fails in add_notes_attrs or
add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
will still return success, but we can't access user interface
on android device.
Patch for make mod_sysfs_setup can check the error of
add_notes_attrs and add_sysfs_attrs
Fi
use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Chunhui-Li/module-abort-module-loading-when-sysfs-setup-suffer-errors/20240907-02
base: https://git.kernel.org/pub/scm/linux/
use '--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Chunhui-Li/module-abort-module-loading-when-sysfs-setup-suffer-errors/20240907-02
base: https://git.kernel.org/pub/scm/linux/
On Fri, Sep 06, 2024 at 07:57:48PM +0800, Chunhui Li wrote:
> When insmod a kernel module, if fails in add_notes_attrs or
> add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
> will still return success, but we can't access user interface
> on android device.
>
> Patch for make mod_sy
When insmod a kernel module, if fails in add_notes_attrs or
add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
will still return success, but we can't access user interface
on android device.
Patch for make mod_sysfs_setup can check the error of
add_notes_attrs and add_sysfs_attrs
Ac
On Wed, Sep 04, 2024 at 08:41:07PM +0800, Chunhui Li wrote:
> When insmod a kernel module, if fails in add_notes_attrs or
> add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
> will still return success, but we can't access user interface
> on android device.
>
> Patch for make mod_sy
When insmod a kernel module, if fails in add_notes_attrs or
add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
will still return success, but we can't access user interface
on android device.
Patch for make mod_sysfs_setup can check the error of
add_notes_attrs and add_sysfs_attrs.
R
On 8/30/24 07:43, Chunhui Li wrote:
> When insmod a kernel module, if fails in add_notes_attrs or
> add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
> will still return success, but we can't access user interface
> on android device.
>
> Patch for make mod_sysfs_setup can check the
'--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Chunhui-Li/module-abort-module-loading-when-sysfs-setup-suffer-errors/20240830-134417
base: https://git.kernel.org/pub/scm/linux/kernel/
'--base' as documented in
https://git-scm.com/docs/git-format-patch#_base_tree_information]
url:
https://github.com/intel-lab-lkp/linux/commits/Chunhui-Li/module-abort-module-loading-when-sysfs-setup-suffer-errors/20240830-134417
base: https://git.kernel.org/pub/scm/linux/kernel/
When insmod a kernel module, if fails in add_notes_attrs or
add_sysfs_attrs such as memory allocation fail, mod_sysfs_setup
will still return success, but we can't access user interface
on android device.
Patch for make mod_sysfs_setup can check the error of
add_notes_attrs and add_sysfs_attrs
Si
- Secure PIL is signed, split firmware images which only TrustZone (TZ) can
authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to the existing wcss PIL driver
earlier in [2], Bjorn suggested not to overlo
On 8/22/2024 4:58 PM, Krzysztof Kozlowski wrote:
On 22/08/2024 12:43, Gokul Sriram P wrote:
On 8/20/2024 4:42 PM, Krzysztof Kozlowski wrote:
On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
This series depends on q6 clock removal series [1].
How? So this cannot be tested and merged?
Yes
On 22/08/2024 12:43, Gokul Sriram P wrote:
>
> On 8/20/2024 4:42 PM, Krzysztof Kozlowski wrote:
>> On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
>>> This series depends on q6 clock removal series [1].
>> How? So this cannot be tested and merged?
>
> Yes. Though TrustZone enables these clock
On 8/20/2024 4:42 PM, Krzysztof Kozlowski wrote:
On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
This series depends on q6 clock removal series [1].
How? So this cannot be tested and merged?
Yes. Though TrustZone enables these clocks, since Linux Kernel will
consider these clock as unu
On 20/08/2024 10:55, Gokul Sriram Palanisamy wrote:
> This series depends on q6 clock removal series [1].
How? So this cannot be tested and merged?
That's second patchset to day with some totally bogus dependencies.
People, stop it.
Best regards,
Krzysztof
This series depends on q6 clock removal series [1].
- Secure PIL is signed, split firmware images which only TrustZone (TZ) can
authenticate and load. Linux kernel will send a request to TZ to
authenticate and load the PIL images.
- When secure PIL support was added to the existing wcss PIL d
From: Masami Hiramatsu (Google)
Add for_each_tracepoint_in_module() function to iterate tracepoints in
a module. This API is needed for handling tracepoints in a loading
module from tracepoint_module_notifier callback function.
This also update for_each_module_tracepoint() to pass the module to
/virtual/misc. The user interaction necessary to load the
test image and test a particular core is the same as the existing scan
test (intel_ifs_0).
During the loading stage, the driver will look for a file named
ff-mm-ss-.sbft in the /lib/firmware/intel/ifs_2 directory.
The hardware interaction
/virtual/misc. The user interaction necessary to load the
test image and test a particular core is the same as the existing scan
test (intel_ifs_0).
During the loading stage, the driver will look for a file named
ff-mm-ss-.sbft in the /lib/firmware/intel/ifs_2 directory.
The hardware interaction
On Fri, Jun 21, 2024 at 04:05:27PM +0200, Daniel von Kirschten wrote:
> Am 18.06.2024 um 21:58 schrieb Luis Chamberlain:
> > On Thu, Jun 06, 2024 at 03:31:49PM +0200, Daniel v. Kirschten wrote:
> > > If a module is being loaded, and the .gnu.linkonce.this_module section
> > > in the module's ELF fi
Am 18.06.2024 um 21:58 schrieb Luis Chamberlain:
On Thu, Jun 06, 2024 at 03:31:49PM +0200, Daniel v. Kirschten wrote:
If a module is being loaded, and the .gnu.linkonce.this_module section
in the module's ELF file does not have the WRITE flag, the kernel will
map the finished module struct of th
On Wed, Jun 19, 2024 at 08:30:37AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
&
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce.
Unsigned module case:
(linux) insmod unsigned.ko
[ 18.714661] Loading of unsigned module is rejected
On 6/19/24 02:54, Luis Chamberlain wrote:
On Fri, Jun 14, 2024 at 09:25:19AM +, Yusong Gao wrote:
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce
On Thu, Jun 06, 2024 at 03:31:49PM +0200, Daniel v. Kirschten wrote:
> If a module is being loaded, and the .gnu.linkonce.this_module section
> in the module's ELF file does not have the WRITE flag, the kernel will
> map the finished module struct of that module as read-only.
> This causes a kernel
On Fri, Jun 14, 2024 at 09:25:19AM +, Yusong Gao wrote:
> Add log information in kernel-space when loading module failures.
> Try to load the unsigned module and the module with bad signature
> when set 1 to /sys/module/module/parameters/sig_enforce.
>
> Unsigned module case:
&
Add log information in kernel-space when loading module failures.
Try to load the unsigned module and the module with bad signature
when set 1 to /sys/module/module/parameters/sig_enforce.
Unsigned module case:
(linux) insmod unsigned.ko
[ 18.714661] Loading of unsigned module is rejected
If a module is being loaded, and the .gnu.linkonce.this_module section
in the module's ELF file does not have the WRITE flag, the kernel will
map the finished module struct of that module as read-only.
This causes a kernel panic when the struct is written to the first time
after it has been marked
On Mon, Apr 15, 2024 at 12:43:16PM +0200, Peter Zijlstra wrote:
> On Thu, Apr 11, 2024 at 07:05:24PM +0300, Mike Rapoport wrote:
> > diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> > index 45a280f2161c..b4d6868df573 100644
> > --- a/arch/x86/kernel/alternative.c
> > +++
On Thu, Apr 11, 2024 at 07:05:24PM +0300, Mike Rapoport wrote:
> diff --git a/arch/x86/kernel/alternative.c b/arch/x86/kernel/alternative.c
> index 45a280f2161c..b4d6868df573 100644
> --- a/arch/x86/kernel/alternative.c
> +++ b/arch/x86/kernel/alternative.c
> @@ -504,17 +513,17 @@ void __init_or_m
On Fri, Apr 12, 2024 at 11:08:00AM +0200, Ingo Molnar wrote:
>
> * Mike Rapoport wrote:
>
> > for (s = start; s < end; s++) {
> > void *addr = (void *)s + *s;
> > + void *wr_addr = addr + module_writable_offset(mod, addr);
>
> So instead of repeating this pattern in a
* Mike Rapoport wrote:
> for (s = start; s < end; s++) {
> void *addr = (void *)s + *s;
> + void *wr_addr = addr + module_writable_offset(mod, addr);
So instead of repeating this pattern in a dozen of places, why not use a
simpler method:
void
From: "Mike Rapoport (IBM)"
When module text memory will be allocated with ROX permissions, the
memory at the actual address where the module will live will contain
invalid instructions and there will be a writable copy that contains the
actual module code.
Update relocations and alternatives pa
Hi,
I encountered the following OOPS when loading a kernel module with insmod. It
occurs
when loading a kernel module with an invalid ELF section header - the Section
name is
invalid and out of bounds into the section name table
Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> >>>> This adds DW-HDMI driver a glue option to disable loading of the CEC
> >>>> sub-driver.
> >>>>
> >>>> On some SoCs, the CEC functionality is enabled in the IP config bits,
> &
On 20/04/2021 17:13, Hans Verkuil wrote:
> On 16/04/2021 13:38, Neil Armstrong wrote:
>> On 16/04/2021 11:58, Laurent Pinchart wrote:
>>> Hi Neil,
>>>
>>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>>>> This adds DW-HDMI dr
On 16/04/2021 13:38, Neil Armstrong wrote:
> On 16/04/2021 11:58, Laurent Pinchart wrote:
>> Hi Neil,
>>
>> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>>> This adds DW-HDMI driver a glue option to disable loading of the CEC
>>> su
From: Dimitar Dimitrov
[ Upstream commit e6d9423d31b2f9bdd0220fd0584e3bb6ed2c4e52 ]
PRU port of GNU Binutils lacks support for separate address spaces.
PRU IRAM addresses are marked with artificial offset to differentiate
them from DRAM addresses. Hence remoteproc must mask IRAM addresses
coming
CC Hans Verkuil
Dne petek, 16. april 2021 ob 13:38:59 CEST je Neil Armstrong napisal(a):
> On 16/04/2021 11:58, Laurent Pinchart wrote:
> > Hi Neil,
> >
> > On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> >> This adds DW-HDMI driver a glue option
On 16/04/2021 11:58, Laurent Pinchart wrote:
> Hi Neil,
>
> On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
>> This adds DW-HDMI driver a glue option to disable loading of the CEC
>> sub-driver.
>>
>> On some SoCs, the CEC functionality is enabl
Hi Neil,
On Fri, Apr 16, 2021 at 11:27:35AM +0200, Neil Armstrong wrote:
> This adds DW-HDMI driver a glue option to disable loading of the CEC
> sub-driver.
>
> On some SoCs, the CEC functionality is enabled in the IP config bits, but the
> CEC bus is non-functional like on Amlo
From: Jernej Skrabec
This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not
This adds DW-HDMI driver a glue option to disable loading of the CEC sub-driver.
On some SoCs, the CEC functionality is enabled in the IP config bits, but the
CEC bus is non-functional like on Amlogic SoCs, where the CEC config bit is set
but the DW-HDMI CEC signal is not connected to a physical
chal Simek ; linux-
> f...@vger.kernel.org; devicet...@vger.kernel.org; linux-arm-
> ker...@lists.infradead.org; linux-kernel@vger.kernel.org; git
> ; chinnikishore...@gmail.com
> Subject: Re: [PATCH 1/2] fpga: mgr: Adds secure BitStream loading support
>
> Hi Nava,
>
>
API for individual devices to register with the syscfg management
system is added.
Devices register with matching information, and any features or
configurations that match will be loaded into the device.
The feature and configuration loading is extended so that on load these
are loaded into any
From: Dimitar Dimitrov
[ Upstream commit e6d9423d31b2f9bdd0220fd0584e3bb6ed2c4e52 ]
PRU port of GNU Binutils lacks support for separate address spaces.
PRU IRAM addresses are marked with artificial offset to differentiate
them from DRAM addresses. Hence remoteproc must mask IRAM addresses
coming
From: Suman Anna
[ Upstream commit 9afeefcf06fc7b4bdab06a6e2cb06745bded34dd ]
The K3 PRUs are 32-bit processors and in general have some limitations
in using the standard ARMv8 memcpy function for loading firmware segments,
so the driver already uses a custom memcpy implementation. This added
trusted keyring.
>
> However, missing from this version was support for the kernel-CA to sign the
> hardware token certificate. Adding that support would add additional
> complexity.
>
> Since the kernel module signing key is embedded into the Linux kernel at
> build time, instead
int load_cert(const u8 *p, const u8 *end, struct key *keyring)
{
key_ref_t key;
- const u8 *p, *end;
size_t plen;
- pr_notice("Loading compiled-in X.509 certificates\n");
-
- p = system_certificate_list;
- end = p + system_certificate_lis
dding that support would add additional
complexity.
Since the kernel module signing key is embedded into the Linux kernel at
build time, instead of creating and loading a kernel-CA onto the builtin
trusted keyring, this version makes an exception and allows the
self-signed kernel module signing
API for individual devices to register with the syscfg management
system is added.
Devices register with matching information, and any features or
configurations that match will be loaded into the device.
The feature and configuration loading is extended so that on load these
are loaded into any
to this approach, and this patch has a plethora of
> issues.
>
> I'm not against deferring various state loading to KVM_RUN, but wholesale
> moving
> all of GUEST_CR3 processing without in-depth consideration of all the side
> effects is a really bad idea.
It could b
1 - 100 of 2119 matches
Mail list logo
