On Wed, 2025-02-05 at 15:28 +0100, Michal Suchánek wrote:
> Hello,
>
> thanks for working on this!
>
> I see in thes version you ended up reusing the existing RTAS call
> code
> which looks better.
>
> From the past discussion it sounds like the get-indices call can list
> the available dumps, a
On 2025/2/6 14:30, Christophe Leroy wrote:
>
>
> Le 06/02/2025 à 03:08, Miaohe Lin a écrit :
>> On 2025/2/6 0:35, Christophe Leroy wrote:
>>>
>>>
>>> Le 05/02/2025 à 03:39, Miaohe Lin a écrit :
On 2025/1/24 6:24, kernel test robot wrote:
> tree:
> https://eur01.safelinks.protectio
Le 06/02/2025 à 03:08, Miaohe Lin a écrit :
On 2025/2/6 0:35, Christophe Leroy wrote:
Le 05/02/2025 à 03:39, Miaohe Lin a écrit :
On 2025/1/24 6:24, kernel test robot wrote:
tree:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fker
On 2/5/25 19:28, Gaurav Batra wrote:
On 2/5/25 6:43 AM, Donet Tom wrote:
On 1/31/25 00:08, Gaurav Batra wrote:
iommu_mem_notifier() is invoked when RAM is dynamically
added/removed. This
notifier call is responsible to add/remove TCEs from the Dynamic DMA
Window
(DDW) when TCEs are pre-map
Several APIs such as rtas_get_indices(), rtas_get_dynamic_sensor(),
rtas_set_dynamic_indicator(), rtas_platform_dump() and
rtas_physical_attestation() provided by librtas library are
implemented in user space using rtas syscall in combination with
writable mappings of /dev/mem. But this implementa
The RTAS call can be normal where retrieves the data form the
hypervisor once or sequence based RTAS call which has to
issue multiple times until the complete data is obtained. For
some of these sequence RTAS calls, the OS should not interleave
calls with different input until the sequence is compl
The RTAS call ibm,physical-attestation is used to retrieve
information about the trusted boot state of the firmware and
hypervisor on the system, and also Trusted Platform Modules (TPM)
data if the system is TCG 2.0 compliant.
This RTAS interface expects the caller to define different command
stru
The RTAS call ibm,get-dynamic-sensor-state is used to get the
sensor state identified by the location code and the sensor
token. The librtas library provides an API
rtas_get_dynamic_sensor() which uses /dev/mem access for work
area allocation but is restricted under system lockdown.
This patch pro
ibm,platform-dump RTAS call in combination with writable mapping
/dev/mem is issued to collect platform dump from the hypervisor
and may need multiple calls to get the complete dump. The current
implementation uses rtas_platform_dump() API provided by librtas
library to issue these RTAS calls. But
The RTAS call ibm,get-indices is used to obtain indices and
location codes for a specified indicator or sensor token. The
current implementation uses rtas_get_indices() API provided by
librtas library which allocates RMO buffer and issue this RTAS
call in the user space. But writable mapping /dev/m
The RTAS call ibm,set-dynamic-indicator is used to set the new
indicator state identified by a location code. The current
implementation uses rtas_set_dynamic_indicator() API provided by
librtas library which allocates RMO buffer and issue this RTAS
call in the user space. But /dev/mem access by th
To issue ibm,get-indices, ibm,set-dynamic-indicator and
ibm,get-dynamic-sensor-state in the user space, the RMO buffer is
allocated for the work area which is restricted under system
lockdown. So instead of user space execution, the kernel will
provide /dev/papr-indices interface to execute these R
On 2/5/25 15:31, Mark Rutland wrote:
> On Wed, Feb 05, 2025 at 10:30:39AM +0530, Anshuman Khandual wrote:
>> GENERIC_PTDUMP does not guard any code but instead just used for platform's
>> subscription into core ptdump defined under PTDUMP_CORE, which is selected.
>
> Selected by what?
I guess
When decimation filter bypass mode is enabled, PDM data can be
written into FIFO directly without any processing.
The interface of this mode is DSD big endian format, when
user needs this format, then this mode is enabled.
This mode is only for the i.MX943 platform currently.
Signed-off-by: Shen
On 2025/2/6 0:35, Christophe Leroy wrote:
>
>
> Le 05/02/2025 à 03:39, Miaohe Lin a écrit :
>> On 2025/1/24 6:24, kernel test robot wrote:
>>> tree:
>>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&da
Vivek Goyal wrote:
> On Fri, Jan 10, 2025 at 05:00:29PM +1100, Alistair Popple wrote:
> > FS DAX requires file systems to call into the DAX layout prior to unlinking
> > inodes to ensure there is no ongoing DMA or other remote access to the
> > direct mapped page. The fuse file system implements
>
On Tue, Jan 28, 2025 at 11:46:32AM -0500, Yury Norov wrote:
> A loop based on cpumask_next_wrap() opencodes the dedicated macro
> for_each_online_cpu_wrap(). Using the macro allows to avoid setting
> bits affinity mask more than once when stride >= num_online_cpus.
>
nit: Same comment as left in p
On 1/31/25 00:08, Gaurav Batra wrote:
iommu_mem_notifier() is invoked when RAM is dynamically added/removed. This
notifier call is responsible to add/remove TCEs from the Dynamic DMA Window
(DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM and not
for persistent memory (pmemory).
Le 05/02/2025 à 03:39, Miaohe Lin a écrit :
On 2025/1/24 6:24, kernel test robot wrote:
tree:
https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgit.kernel.org%2Fpub%2Fscm%2Flinux%2Fkernel%2Fgit%2Ftorvalds%2Flinux.git&data=05%7C02%7Cchristophe.leroy%40csgroup.eu%7C9284805dd2
On 2/5/25 6:43 AM, Donet Tom wrote:
On 1/31/25 00:08, Gaurav Batra wrote:
iommu_mem_notifier() is invoked when RAM is dynamically
added/removed. This
notifier call is responsible to add/remove TCEs from the Dynamic DMA
Window
(DDW) when TCEs are pre-mapped. TCEs are pre-mapped only for RAM
6.13-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
[ Upstream commit a145c848d69f9c6f32008d8319edaa133360dd74 ]
dereference_symbol_descriptor() needs to obtain the module pointer
belonging to pointer in order to resol
6.12-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
[ Upstream commit a145c848d69f9c6f32008d8319edaa133360dd74 ]
dereference_symbol_descriptor() needs to obtain the module pointer
belonging to pointer in order to resol
6.13-stable review patch. If anyone has any objections, please let me know.
--
From: Christophe Leroy
[ Upstream commit 7a93786c306296f15e728b1dbd949a319e4e3d19 ]
Depending on how vmlinux.lds is written, _etext might be the very first
data symbol instead of the very last text
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Sebastian Andrzej Siewior
[ Upstream commit a145c848d69f9c6f32008d8319edaa133360dd74 ]
dereference_symbol_descriptor() needs to obtain the module pointer
belonging to pointer in order to resolv
6.12-stable review patch. If anyone has any objections, please let me know.
--
From: Christophe Leroy
[ Upstream commit 7a93786c306296f15e728b1dbd949a319e4e3d19 ]
Depending on how vmlinux.lds is written, _etext might be the very first
data symbol instead of the very last text
On Sun, Jan 26, 2025 at 11:09:01PM -0600, Rob Herring wrote:
> On Sun, Jan 26, 2025 at 07:59:03PM +0100, J. Neuschäfer wrote:
> > fsl-spi.txt contains the bindings for the fsl,spi and fsl,espi
> > contollers. Convert them to YAML.
> >
> > Signed-off-by: J. Neuschäfer
> > ---
> > .../devicetree/b
Hello,
thanks for working on this!
I see in thes version you ended up reusing the existing RTAS call code
which looks better.
>From the past discussion it sounds like the get-indices call can list
the available dumps, and I do not see this connection documented.
Also the part about it not being
The space separator was factored out from the multiple chip name prints,
but several irq_chip.irq_print_chip() callbacks still print a leading
space. Remove the superfluous double spaces.
Fixes: 9d9f204bdf7243bf ("genirq/proc: Add missing space separator back")
Signed-off-by: Geert Uytterhoeven
6.6-stable review patch. If anyone has any objections, please let me know.
--
From: Christophe Leroy
[ Upstream commit 7a93786c306296f15e728b1dbd949a319e4e3d19 ]
Depending on how vmlinux.lds is written, _etext might be the very first
data symbol instead of the very last text s
On Fri, Jan 10, 2025 at 05:00:29PM +1100, Alistair Popple wrote:
> FS DAX requires file systems to call into the DAX layout prior to unlinking
> inodes to ensure there is no ongoing DMA or other remote access to the
> direct mapped page. The fuse file system implements
> fuse_dax_break_layouts() to
div128_by_32() used to be called from outside time.c in the old days
but since v2.6.15 it hasn't been used outside time.c
$ git grep div128_by_32 v2.6.14
v2.6.14:arch/ppc64/kernel/iSeries_setup.c: div128_by_32(1024 * 1024, 0,
tb_ticks_per_sec, &divres);
v2.6.14:arch/ppc64/kernel/pmac_time.c:
On Wed, Feb 05, 2025 at 10:30:39AM +0530, Anshuman Khandual wrote:
> GENERIC_PTDUMP does not guard any code but instead just used for platform's
> subscription into core ptdump defined under PTDUMP_CORE, which is selected.
Selected by what?
> Instead use PTDUMP_CORE for platform subscription and
On Tue, Feb 04, 2025 at 11:06:08AM -0800, Dan Williams wrote:
> Alistair Popple wrote:
> > On Tue, Jan 14, 2025 at 10:50:49AM -0800, Dan Williams wrote:
> > > Alistair Popple wrote:
> > > > The devmap PTE special bit was used to detect mappings of FS DAX
> > > > pages. This tracking was required to
Christophe Leroy writes:
> Erhard reports the following KASAN hit on Talos II (power9) with kernel 6.13:
>
> [ 12.028126]
> ==
> [ 12.028198] BUG: KASAN: user-memory-access in
> copy_to_kernel_nofault+0x8c/0x1a0
> [ 12.028260]
Le 04/02/2025 à 13:05, Thomas Weißschuh a écrit :
The generic storage implementation provides the same features as the
custom one. However it can be shared between architectures, making
maintenance easier.
Co-developed-by: Nam Cao
Signed-off-by: Nam Cao
Signed-off-by: Thomas Weißschuh
Re
35 matches
Mail list logo
