On 2023/7/14 9:52, Kefeng Wang wrote:
On 2023/7/14 4:12, Suren Baghdasaryan wrote:
On Thu, Jul 13, 2023 at 9:15 AM Matthew Wilcox
wrote:
+int try_vma_locked_page_fault(struct vm_locked_fault *vmlf,
vm_fault_t *ret)
+{
+ struct vm_area_struct *vma;
+ vm_fault_t fault;
On
On Mon, Jun 12, 2023 at 05:10:27PM -0700, Rick Edgecombe wrote:
> The x86 Shadow stack feature includes a new type of memory called shadow
> stack. This shadow stack memory has some unusual properties, which requires
> some core mm changes to function properly.
This seems to break
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
Thanks.
-Danny
From: Herbert Xu
Sent: Friday, July 14, 2023 4:49 PM
To: Danny Tsen
Cc: linux-cry...@vger.kernel.org ;
lei...@debian.org ; na...@linux.ibm.com
; ap...@cryptogams.org ;
linux-ker...@vger.kernel.org ;
linuxppc-dev@lists.ozlabs.org ;
On Fri, Jul 14, 2023 at 09:05:21AM +0200, Christian Brauner wrote:
> I have no skin in the game aside from having to drop this conversion
> which I'm fine to do if there are actually users for this btu really,
> that looks a lot like abusing an api that really wasn't designed for
> this.
Yeah, I
On 2023/7/14 15:49, Thomas Zimmermann wrote:
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda
Signed-off-by: Thomas Zimmermann
Reviewed-by:
On Thu, Jul 13, 2023 at 11:10:54AM -0600, Alex Williamson wrote:
> On Thu, 13 Jul 2023 12:05:36 +0200
> Christian Brauner wrote:
>
> > Hey everyone,
> >
> > This simplifies the eventfd_signal() and eventfd_signal_mask() helpers
> > by removing the count argument which is effectively unused.
>
On 7/13/23 02:08, David Hildenbrand wrote:
...
**WEAK_DECLARATION**
Using weak declarations like __attribute__((weak)) or __weak
can have unintended link defects. Avoid using them.
...which seems deeply out of touch with how arch layers work these days,
doesn't it? (This is not
On Fri, 14 Jul 2023 17:29:12 +0800, Chancel Liu wrote:
> Add compatible string for i.MX93 platform which supports audio
> function through rpmsg channel between Cortex-A and Cortex-M core.
>
> Signed-off-by: Chancel Liu
> ---
> Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml | 1 +
> 1
Thomas,
On 7/13/23 09:11, Randy Dunlap wrote:
>
>
> On 7/12/23 19:37, Stephen Rothwell wrote:
>> Hi all,
>>
I still see this build error on linux-next 20230714.
>> Changes since 20230712:
>>
>
> on ppc64:
>
> In file included from ../inclu
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
The DT of_device.h and of_platform.h date back to the separate
of_platform_bus_type before it as merged into the regular platform bus.
As part of that merge prepping Arm DT support 13 years ago, they
"temporarily" include each other. They also include platform_device.h
and of.h. As a result,
On secure boot enabled PowerVM LPAR, third party code signing keys are
needed during early boot to verify signed third party modules. These
third party keys are stored in moduledb object in the Platform
KeyStore(PKS).
Load third party code signing keys onto .secondary_trusted_keys keyring.
Update Kconfig to enable machine keyring and limit to CA certificates
on PowerVM.
Signed-off-by: Nayna Jain
---
security/integrity/Kconfig | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/security/integrity/Kconfig b/security/integrity/Kconfig
index
trust_moklist() is specific to UEFI enabled systems. Other platforms
rely only on the Kconfig.
Define a generic wrapper named imputed_trust_enabled().
Signed-off-by: Nayna Jain
---
security/integrity/digsig.c | 2 +-
security/integrity/integrity.h| 5
trust_mok variable is accessed within a single function locally.
Change trust_mok from global to local static variable.
Signed-off-by: Nayna Jain
---
security/integrity/platform_certs/machine_keyring.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git
Keys that derive their trust from an entity such as a security officer,
administrator, system owner, or machine owner are said to have "imputed
trust". CA keys with imputed trust can be loaded onto the machine keyring.
The mechanism for loading these keys onto the machine keyring is platform
On non-UEFI platforms, handle restrict_link_by_ca failures differently.
Certificates which do not satisfy CA restrictions on non-UEFI platforms
are ignored.
Signed-off-by: Nayna Jain
---
security/integrity/platform_certs/machine_keyring.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
On a secure boot enabled PowerVM guest, local and third party code signing
keys are needed to verify signed applications, configuration files, and
kernel modules.
Loading these keys onto either the .secondary_trusted_keys or .ima
keyrings requires the certificates be signed by keys on the
On 7/12/23 8:32 PM, Valentin Schneider wrote:
> On 12/07/23 16:10, Peter Zijlstra wrote:
>> Hi
>>
>> Thomas just tripped over the x86 topology setup creating a 'DIE' domain
>> for the package mask :-)
>>
>> Since these names are SCHED_DEBUG only, rename them.
>> I don't think anybody *should*
On Wed, Jul 12, 2023 at 04:10:56PM +0200, Peter Zijlstra wrote:
> Hi
>
> Thomas just tripped over the x86 topology setup creating a 'DIE' domain
> for the package mask :-)
>
> Since these names are SCHED_DEBUG only, rename them.
> I don't think anybody *should* be relying on this, but who knows.
Hi
Am 14.07.23 um 12:29 schrieb Dan Carpenter:
On Fri, Jul 14, 2023 at 12:24:05PM +0200, Thomas Zimmermann wrote:
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
On Fri, Jul 14, 2023 at 12:24:05PM +0200, Thomas Zimmermann wrote:
> >
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag FBINFO_DEFAULT from fbdev drivers
> > >fbdev: Remove flag
Hi
Am 14.07.23 um 12:04 schrieb Geert Uytterhoeven:
Hi Thomas,
On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann wrote:
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special
Hi Thomas,
On Fri, Jul 14, 2023 at 9:53 AM Thomas Zimmermann wrote:
> Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
> fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
> useful when fbdev had special handling for driver modules. With
> commit
Add compatible string and specific soc data to support rpmsg sound card
on i.MX93 platform.
Signed-off-by: Chancel Liu
---
sound/soc/fsl/fsl_rpmsg.c | 8
1 file changed, 8 insertions(+)
diff --git a/sound/soc/fsl/fsl_rpmsg.c b/sound/soc/fsl/fsl_rpmsg.c
index 15b48b5ea856..abe19a8a7aa7
Add compatible string for i.MX93 platform which supports audio
function through rpmsg channel between Cortex-A and Cortex-M core.
Signed-off-by: Chancel Liu
---
Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml | 1 +
1 file changed, 1 insertion(+)
diff --git
Support rpmsg sound card on i.MX93 platform.
Chancel Liu (2):
ASoC: dt-bindings: fsl_rpmsg: Add compatible string for i.MX93
ASoC: fsl_rpmsg: Add support for i.MX93 platform
Documentation/devicetree/bindings/sound/fsl,rpmsg.yaml | 1 +
sound/soc/fsl/fsl_rpmsg.c
On Wed, Jul 12, 2023 at 04:02:38PM +0100, Valentin Schneider wrote:
> On 12/07/23 16:10, Peter Zijlstra wrote:
> > Hi
> >
> > Thomas just tripped over the x86 topology setup creating a 'DIE' domain
> > for the package mask :-)
> >
> > Since these names are SCHED_DEBUG only, rename them.
> > I
On Wed, Apr 26, 2023 at 03:11:42PM -0400, Danny Tsen wrote:
> This patch series provide an accelerated/optimized Chacha20 and Poly1305
> implementation for Power10 or later CPU (ppc64le). This module
> implements algorithm specified in RFC7539. The implementation
> provides 3.5X better
On Fri, May 12, 2023 at 8:01 AM Kai-Heng Feng
wrote:
>
> PCIe services that share an IRQ with PME, such as AER or DPC, may cause a
> spurious wakeup on system suspend. To prevent this, disable the AER interrupt
> notification during the system suspend process.
>
> As Per PCIe Base Spec 5.0,
Most fbdev drivers depend on framebuffer_alloc() to initialize the
allocated memory to 0. Document this guarantee.
v3:
* slightly reword the sentence (Miguel)
Suggested-by: Miguel Ojeda
Signed-off-by: Thomas Zimmermann
Reviewed-by: Miguel Ojeda
Cc: Helge Deller
---
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT. No
functional changes.
Signed-off-by: Thomas Zimmermann
Acked-by: Sam Ravnborg
Cc: Helge Deller
---
include/linux/fb.h | 3 ---
1 file changed, 3 deletions(-)
diff --git a/include/linux/fb.h b/include/linux/fb.h
index
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by devm_kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by a static declaration. So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So
do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by kzalloc(). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
The flag FBINFO_FLAG_DEFAULT is 0 and has no effect, as struct
fbinfo.flags has been allocated to zero by framebuffer_alloc(). So do
not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
*
Assign FB_MODE_IS_UNKNOWN to sh7763fb_videomode.flag instead of
FBINFO_FLAG_DEFAULT. Both are 0, so the stored value does not change.
FBINFO_FLAG_DEFAULT is a flag for a framebuffer in struct fb_info.
Flags for videomodes are prefixed with FB_MODE_.
v3:
* include board name in commit
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by dmam_alloc_coherent(__GFP_ZERO). So do not
set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by framebuffer_alloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by devm_kzalloc(). So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix commit
Remove the unused flags FBINFO_DEFAULT and FBINFO_FLAG_DEFAULT from
fbdev and drivers, as briefly discussed at [1]. Both flags were maybe
useful when fbdev had special handling for driver modules. With
commit 376b3ff54c9a ("fbdev: Nuke FBINFO_MODULE"), they are both 0
and have no further effect.
The flag FBINFO_DEFAULT is 0 and has no effect, as struct fbinfo.flags
has been allocated to zero by a static declaration. So do not set it.
Flags should signal differences from the default values. After cleaning
up all occurrences of FBINFO_DEFAULT, the token will be removed.
v2:
* fix
Thanks Randy for the review comments, I will do these updates
for all documentation patches in my next version of patchset.
Thanks,
Kajol Jain
On 7/12/23 02:22, Randy Dunlap wrote:
> Hi--
>
> On 7/10/23 02:27, Kajol Jain wrote:
>> Add details of the new hv-gpci interface file called
57 matches
Mail list logo
