On Tue, 23 Jul 2024 at 14:01, Jason Wang wrote:
>
> On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
> >
> > Add new UAPI to support the mac address from vdpa tool
> > Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> > new MAC address from the vdpa tool and then set it to the device.
> >
>
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
Acked-by: Jason Wang
Thanks
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa_sim_net, the driver will write the MAC address
> to the config space, and other devices can implement
> their own functions to support this.
>
> Signed-off-by: Cindy Lu
Acked-by:
On Tue, Jul 23, 2024 at 1:41 PM Cindy Lu wrote:
>
> Add new UAPI to support the mac address from vdpa tool
> Function vdpa_nl_cmd_dev_attr_set_doit() will get the
> new MAC address from the vdpa tool and then set it to the device.
>
> The usage is: vdpa dev set name vdpa_name mac
On Tue, 16 Jul 2024, Mike Rapoport wrote:\n
From: "Mike Rapoport (Microsoft)"
Every architecture that supports NUMA defines node_data in the same way:
struct pglist_data *node_data[MAX_NUMNODES];
No reason to keep multiple copies of this definition and its forward
declarations,
Thanks for the review, Kirill.
On Mon, Jul 08, 2024 at 03:19:54PM +0300, Kirill A . Shutemov wrote:
> Hm. Per-thread flag is odd. I think it should be per-process.
This is the only point I might need some clarification on. I agree
there doesn't seem to be much value in allowing per-thread
On Tue, 23 Jul 2024 at 09:28, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 10:48 PM Cindy Lu wrote:
> >
> > On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
> > >
> > > On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> > > >
> > > > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > >
On Mon, Jul 22, 2024 at 5:45 PM Dragos Tatulea wrote:
>
> On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > >
On Mon, Jul 22, 2024 at 10:48 PM Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
> >
> > On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> > >
> > > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > > >
> >
On Fri, 19 Jul 2024 22:47:01 +0200
Mathias Krause wrote:
> Subject: [PATCH] eventfs: Don't return NULL in eventfs_create_dir()
>
> Commit 77a06c33a22d ("eventfs: Test for ei->is_freed when accessing
> ei->dentry") added another check, testing if the parent was freed after
> we released the
On Mon, Jul 22, 2024 at 11:21 AM wrote:
>
> From: Matteo Croce
>
> The helper bpf_current_task_under_cgroup() currently is only allowed for
> tracing programs.
> Allow its usage also in the BPF_CGROUP_* program types.
> Move the code from kernel/trace/bpf_trace.c to kernel/bpf/cgroup.c,
> so it
Good morning,
On Mon, Jul 15, 2024 at 06:39:54PM -0700, Tanmay Shah wrote:
> AMD-Xilinx zynqmp platform contains on-chip sram memory (OCM).
> R5 cores can access OCM and access is faster than DDR memory but slower
> than TCM memories available. Sram region can have optional multiple
>
Hi Adam,
kernel test robot noticed the following build warnings:
[auto build test WARNING on v6.10]
[also build test WARNING on linus/master next-20240722]
[cannot apply to broonie-sound/for-next]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch,
On Mon, 22 Jul 2024 at 20:55, Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
> >
> > On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > > >
> > > > Add the function to support setting the MAC address.
> > > >
On Mon, 22 Jul 2024 at 17:45, Dragos Tatulea wrote:
>
> On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > > to
On Mon, 22 Jul 2024 at 15:49, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
> >
On Mon, Jul 22, 2024 at 11:51:05AM GMT, Adam Skladowski wrote:
> From: Vladimir Lypak
>
> Add support for configuring Quinary Mi2S interface
> it will be used on MSM8953 and MSM8976 platform.
>
> Signed-off-by: Vladimir Lypak
> [Adam: Split from MSM8953 support patch,add msg]
> Signed-off-by:
On Sat, Jul 20, 2024 at 2:17 AM Mathias Krause wrote:
>
> Hi Steven, Ajay,
>
> [ @Cc list: I found out issues with tracefs have been reported /
> attempted to get fixed in the past, so you may be interested. ]
>
> I noticed, the user events ftrace selftest is crashing every now and
> then in
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Enable [A,C]DSP and MPSS remote processor on this device.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The USB-C port is used for powering external devices and transfer
> data from/to them.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konradqmpphy_out {
> + remote-endpoint = <_ss_in>;
> +};
> +
> _board {
> clock-frequency
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The F(x)tec Pro1X supports USB 3.0 through it's USB-C port.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On Mon, Jul 22, 2024 at 6:07 PM Petr Pavlu wrote:
>
> The kernel configuration allows specifying a module compression mode. If
> one is selected then each module gets compressed during
> 'make modules_install' and additionally one can also enable support for
> a respective direct in-kernel
On 22.07.2024 11:17 AM, Dang Huynh wrote:
>>> +_dsi0_phy {
>>> + status = "okay";
>>
>> No power supplies?
>>
>> Konrad
>
> Doesn't seem to be defined anywhere on downstream, may be hardware controlled.
my downstream suggests L1b
Konrad
On Mon, 2024-07-22 at 15:48 +0800, Jason Wang wrote:
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> > to set the mac address
> >
> > Tested in ConnectX-6 Dx device
> >
>
> > +_dsi0_phy {
> > + status = "okay";
>
> No power supplies?
>
> Konrad
Doesn't seem to be defined anywhere on downstream, may be hardware controlled.
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Enable onboard Wi-Fi on the F(x)tec Pro1X.
>
> For reference, HW/SW identifies as:
> qmi chip_id 0x120 chip_family 0x4007 board_id 0xff soc_id 0x4067
> qmi fw_version 0x324103d6 fw_build_timestamp 2021-12-02 08:20
> fw_build_id
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> This device has an RGB LED. It is used for notifications.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> Fxtec Pro1x uses the same display (BOE BF060Y8M-AJ0) as Pro1.
>
> Signed-off-by: Dang Huynh
> ---
[...]
> + panel: panel@0 {
> + compatible = "boe,bf060y8m-aj0";
> + reg = <0>;
> +
> + reset-gpios = < 82
> On 22.07.2024 9:10 AM, Dang Huynh wrote:
> > +
> > + ts_vdd_supply: ts-vdd-supply {
> > + compatible = "regulator-fixed";
> > + regulator-name = "ts_vdd_supply";
> > + gpio = < 3 GPIO_ACTIVE_HIGH>;
> > + enable-active-high;
> > + };
> > +
> > +
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Pro1X has a caps lock LED on the keyboard.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 11 +++
> 1 file changed, 11 insertions(+)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Fxtec Pro1X touchscreen uses Goodix GT9286 chip.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 49
> +
> 1 file changed, 49 insertions(+)
>
> diff --git
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> F(x)tec Pro1X comes with PCA9534 IO Expander, it is used for enabling
> touch screen VDD/VDDIO and keyboard's caps lock LED.
>
> Signed-off-by: Dang Huynh
> ---
Reviewed-by: Konrad Dybcio
Konrad
On 22.07.2024 9:10 AM, Dang Huynh wrote:
> The Pro1X has a flip keyboard and a single-state camera button.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 33
> +++--
> 1 file changed, 31 insertions(+), 2 deletions(-)
>
> diff --git
On 7/15/24 22:39, Sami Tolvanen wrote:
> On Wed, Jul 10, 2024 at 7:30 AM Petr Pavlu wrote:
>> On 6/17/24 19:58, Sami Tolvanen wrote:
>>> The first 12 patches of this series add a small tool for computing
>>> symbol versions from DWARF, called gendwarfksyms. When passed a list
>>> of exported
On Fri, Jul 19, 2024 at 02:33:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:29 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Hi,
> >
> > Following the discussion about handling of CXL fixed memory windows on
> > arm64 [1] I decided to bite the
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:44 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Introduce numa_memblks_init() and move some code around to avoid several
> > global variables in numa_memblks.
>
> Hi
On Fri, Jul 19, 2024 at 07:16:47PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:41 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
> > options to let x86 select it in its
On Mon, Jul 22, 2024 at 3:57 PM Cindy Lu wrote:
>
> On Mon, 22 Jul 2024 at 15:48, Jason Wang wrote:
> >
> > On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> > >
> > > Add the function to support setting the MAC address.
> > > For vdpa_sim_net, the driver will write the MAC address
> > > to the
On Mon, 22 Jul 2024 at 15:48, Jason Wang wrote:
>
> On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
> >
> > Add the function to support setting the MAC address.
> > For vdpa_sim_net, the driver will write the MAC address
> > to the config space, and other devices can implement
> > their own
On Fri, Jul 19, 2024 at 05:28:49PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:35 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Allocation of numa_distance uses memblock_phys_alloc_range() to limit
> > allocation to be below the last mapped page.
>
On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa/mlx5, the function will use mlx5_mpfs_add_mac
> to set the mac address
>
> Tested in ConnectX-6 Dx device
>
> Signed-off-by: Cindy Lu
> ---
> drivers/vdpa/mlx5/net/mlx5_vnet.c |
On Mon, Jul 22, 2024 at 9:06 AM Cindy Lu wrote:
>
> Add the function to support setting the MAC address.
> For vdpa_sim_net, the driver will write the MAC address
> to the config space, and other devices can implement
> their own functions to support this.
>
> Signed-off-by: Cindy Lu
> ---
>
On Fri, Jul 19, 2024 at 03:38:52PM +0100, Jonathan Cameron wrote:
> On Wed, 17 Jul 2024 16:32:59 +0200
> David Hildenbrand wrote:
>
> > On 16.07.24 13:13, Mike Rapoport wrote:
> > > From: "Mike Rapoport (Microsoft)"
> > >
> > > sgi-ip27 is the only system that defines NODE_DATA() differently
On 22/07/2024 09:10, Dang Huynh wrote:
> It's 2024, let's update the copyright year.
>
> Signed-off-by: Dang Huynh
> ---
> arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/arch/arm64/boot/dts/qcom/sm6115-fxtec-pro1x.dts
>
On Thu, Jul 18, 2024 at 2:28 AM Steven Sistare
wrote:
>
> On 7/16/2024 1:16 AM, Jason Wang wrote:
> > On Mon, Jul 15, 2024 at 10:27 PM Steven Sistare
> > wrote:
> >>
> >> On 7/14/2024 10:26 PM, Jason Wang wrote:
> >>> On Fri, Jul 12, 2024 at 9:19 PM Steve Sistare
> >>> wrote:
>
> Add
On Fri, Jul 19, 2024 at 9:19 AM Michael S. Tsirkin wrote:
>
> On Fri, Jul 19, 2024 at 09:02:29AM +0800, Jason Wang wrote:
> > On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote:
> > >
> > > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin
> > > wrote:
> > > >
> > > > On Wed, Jul 17, 2024 at
On Wed, 2024-07-10 at 17:19 +0800, Tze-nan Wu wrote:
> "tracing_map->next_elt" in get_free_elt() is at risk of overflowing.
>
> Once it overflows, new elements can still be inserted into the
> tracing_map
> even though the maximum number of elements (`max_elts`) has been
> reached.
> Continuing
On 2024/7/20 22:14, Masahiro Yamada wrote:
On Thu, Jul 18, 2024 at 12:45 PM Zheng Yejian wrote:
On 2024/7/16 16:33, Masahiro Yamada wrote:
On Thu, Jun 13, 2024 at 10:36 PM Zheng Yejian wrote:
When a weak type function is overridden, its symbol will be removed
from the symbol table, but
On Fri, 2024-07-19 at 17:33 +0800, Yunsheng Lin wrote:
> Use appropriate frag_page API instead of caller accessing
> 'page_frag_cache' directly.
>
> CC: Alexander Duyck
> Signed-off-by: Yunsheng Lin
> ---
> drivers/vhost/net.c | 2 +-
> include/linux/page_frag_cache.h | 10
On Fri, Jul 19, 2024 at 2:37 AM Yunsheng Lin wrote:
>
> Currently the page_frag API is returning 'virtual address'
> or 'va' when allocing and expecting 'virtual address' or
> 'va' as input when freeing.
>
> As we are about to support new use cases that the caller
> need to deal with 'struct
Hi,
On Tue, May 14, 2024 at 06:05:20PM +0200, Guido Günther wrote:
> Hi,
> On Mon, May 13, 2024 at 03:13:53PM -0700, Dmitry Torokhov wrote:
> > Hi Guido,
> >
> > On Thu, May 09, 2024 at 02:00:28PM +0200, Guido Günther wrote:
> > > This helps user space to figure out which keys should be used to
completion of in-progress DMA. At least, that is
my interpretation of why that is done for live migration in QEMU, which
also does suspend + reset + re-create. I am following the live migration
model.
Yes, but any reason we need a reset after the suspension?
Probably not. I found it cleanest
The pull request you sent on Fri, 19 Jul 2024 11:19:47 -0500:
> git://git.kernel.org/pub/scm/linux/kernel/git/nvdimm/nvdimm.git
> tags/libnvdimm-for-6.11
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/13a7871541b7f5fa6d81e76f160644d1e118b6b0
Thank you!
--
On Thu, 18 Jul 2024 13:30:57 -0500
Dan Carpenter wrote:
> Hello Masami Hiramatsu (Google),
>
> Commit 9d8616034f16 ("tracing/kprobes: Add symbol counting check when
> module loads") from Jul 5, 2024 (linux-next), leads to the following
> Smatch static checker warning:
>
>
On Thu, Jul 18, 2024 at 12:45 PM Zheng Yejian wrote:
>
> On 2024/7/16 16:33, Masahiro Yamada wrote:
> > On Thu, Jun 13, 2024 at 10:36 PM Zheng Yejian
> > wrote:
> >>
> >> When a weak type function is overridden, its symbol will be removed
> >> from the symbol table, but its code will not be
On Fri, Jul 19, 2024 at 07:07:12PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:44 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Introduce numa_memblks_init() and move some code around to avoid several
> > global variables in numa_memblks.
>
> Hi
On Fri, Jul 19, 2024 at 06:48:42PM +0100, Jonathan Cameron wrote:
> On Tue, 16 Jul 2024 14:13:42 +0300
> Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_distance array from arch/x86 to
> > mm/numa_memblks.c
>
> It's not really numa memblock
On Fri, Jul 19, 2024 at 12:03:11PM -0400, Zi Yan wrote:
> On 16 Jul 2024, at 7:13, Mike Rapoport wrote:
>
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move numa_emulation codfrom arch/x86 to mm/numa_emulation.c
> >
> > This code will be later reused by arch_numa.
> >
> > No functional changes.
On Wed, Jul 17, 2024 at 04:42:48PM +0200, David Hildenbrand wrote:
> On 16.07.24 13:13, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Architectures that support NUMA duplicate the code that allocates
> > NODE_DATA on the node-local memory with slight variations in reporting
> is this always correct though? See the logic in klp_ftrace_handler(). If
> there is a transition running, it is a little bit more complicated.
>
> Miroslav
Hi! Miroslav.
In reality, we often encounter such situation that serval patch in one system,
some patch make changes to one same
On Fri, Jul 19, 2024 at 10:47:01PM +0200, Mathias Krause wrote:
> Hi Steven, Ajay,
>
> [ @Cc list: I found out issues with tracefs have been reported /
> attempted to get fixed in the past, so you may be interested. ]
>
> I noticed, the user events ftrace selftest is crashing every now and
>
The pull request you sent on Wed, 17 Jul 2024 05:30:34 -0400:
> https://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost.git tags/for_linus
has been merged into torvalds/linux.git:
https://git.kernel.org/torvalds/c/f4f92db4391285ef3a688cdad25d5c76db200a30
Thank you!
--
Deet-doot-dot, I am a
On Mon, Jul 15, 2024 at 11:10 AM Andrii Nakryiko
wrote:
>
> On Mon, Jul 15, 2024 at 10:10 AM Andrii Nakryiko
> wrote:
> >
> > On Mon, Jul 15, 2024 at 7:45 AM Peter Zijlstra wrote:
> > >
> > > On Thu, Jul 11, 2024 at 09:57:44PM -0700, Andrii Nakryiko wrote:
> > >
> > > > But then I also ran it
On Tue, 16 Jul 2024 14:13:46 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> The x86 implementation of range-to-target_node lookup (i.e.
> phys_to_target_node() and memory_add_physaddr_to_nid()) relies on
> numa_memblks.
>
> Since numa_memblks are now part of the generic
On Tue, 16 Jul 2024 14:13:41 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Move code dealing with numa_memblks from arch/x86 to mm/ and add Kconfig
> options to let x86 select it in its Kconfig.
>
> This code will be later reused by arch_numa.
>
> No functional changes.
On Tue, 16 Jul 2024 14:13:45 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Until now arch_numa was directly translating firmware NUMA information
> to memblock.
>
> Using numa_memblks as an intermediate step has a few advantages:
> * alignment with more battle tested x86
On Tue, 16 Jul 2024 14:13:44 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Introduce numa_memblks_init() and move some code around to avoid several
> global variables in numa_memblks.
Hi Mike,
Adding the effectively always on memblock_force_top_down
deserves a comment on
On Tue, 16 Jul 2024 14:13:42 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Move code dealing with numa_distance array from arch/x86 to
> mm/numa_memblks.c
It's not really numa memblock related. Is this the best place
to put it?
>
> This code will be later reused by
On Tue, 16 Jul 2024 14:13:40 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> CPU id cannot be negative.
>
> Making it unsigned also aligns with declarations in
> include/asm-generic/numa.h used by arm64 and riscv and allows sharing
> numa emulation code with these
On Tue, 16 Jul 2024 14:13:39 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> This is required to make numa emulation code architecture independent s
> that it can be moved to generic code in following commits.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Reviewed-by:
On Tue, 16 Jul 2024 14:13:38 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> This is required to make numa emulation code architecture independent so
> that it can be moved to generic code in following commits.
>
> Signed-off-by: Mike Rapoport (Microsoft)
Not the most
On Tue, 16 Jul 2024 14:13:37 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> By the time numa_emulation() is called, all physical memory is already
> mapped in the direct map and there is no need to define limits for
> memblock allocation.
>
> Replace
On Tue, 16 Jul 2024 14:13:36 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> The definitions of FAKE_NODE_MIN_SIZE and FAKE_NODE_MIN_HASH_MASK are
> only used by numa emulation code, make them local to
> arch/x86/mm/numa_emulation.c
>
> Signed-off-by: Mike Rapoport
On Tue, 16 Jul 2024 14:13:35 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Allocation of numa_distance uses memblock_phys_alloc_range() to limit
> allocation to be below the last mapped page.
>
> But NUMA initializaition runs after the direct map is populated and
On Tue, 16 Jul 2024 14:13:34 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Architectures that support NUMA duplicate the code that allocates
> NODE_DATA on the node-local memory with slight variations in reporting
> of the addresses where the memory was allocated.
>
> Use
On 19.07.24 17:51, Jonathan Cameron wrote:
On Fri, 19 Jul 2024 17:07:35 +0200
David Hildenbrand wrote:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size,
On 16 Jul 2024, at 7:13, Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Move numa_emulation codfrom arch/x86 to mm/numa_emulation.c
>
> This code will be later reused by arch_numa.
>
> No functional changes.
>
> Signed-off-by: Mike Rapoport (Microsoft)
> ---
> arch/x86/Kconfig
* Li, Fei1 (fei1...@intel.com) wrote:
> > -Original Message-
> > From: Dr. David Alan Gilbert
> > Sent: Friday, July 19, 2024 1:44 AM
> > To: Li, Fei1
> > Cc: linux-kernel@vger.kernel.org; virtualizat...@lists.linux.dev
> > Subject: Re: [PA
On Fri, 19 Jul 2024 17:07:35 +0200
David Hildenbrand wrote:
> >>> - * Allocate node data. Try node-local memory and then any node.
> >>> - * Never allocate in DMA zone.
> >>> - */
> >>> - nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
> >>> - if (!nd_pa) {
> >>> -
On 19.07.24 17:34, Mike Rapoport wrote:
On Fri, Jul 19, 2024 at 05:07:35PM +0200, David Hildenbrand wrote:
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size,
On Tue, 16 Jul 2024 14:13:33 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Every architecture that supports NUMA defines node_data in the same way:
>
> struct pglist_data *node_data[MAX_NUMNODES];
>
> No reason to keep multiple copies of this definition and its
On Fri, Jul 19, 2024 at 05:07:35PM +0200, David Hildenbrand wrote:
> > > > -* Allocate node data. Try node-local memory and then any node.
> > > > -* Never allocate in DMA zone.
> > > > -*/
> > > > - nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES,
> >
On Tue, 16 Jul 2024 14:13:32 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Make definition of node_data match other architectures.
> This will allow pulling declaration of node_data to the generic mm code in
> the following commit.
>
> Signed-off-by: Mike Rapoport
-* Allocate node data. Try node-local memory and then any node.
-* Never allocate in DMA zone.
-*/
- nd_pa = memblock_phys_alloc_try_nid(nd_size, SMP_CACHE_BYTES, nid);
- if (!nd_pa) {
- pr_err("Cannot find %zu bytes in any node (initial node:
On Wed, 17 Jul 2024 16:32:59 +0200
David Hildenbrand wrote:
> On 16.07.24 13:13, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > sgi-ip27 is the only system that defines NODE_DATA() differently than
> > the rest of NUMA machines.
> >
> > Add node_data array of struct pglist
On Fri, 19 Jul 2024 12:26:33 +0200
Arnd Bergmann wrote:
> From: Arnd Bergmann
>
> This variable is used only in an #ifdef, which causes a W=1 warning
> with some compilers:
>
> kernel/trace/trace.c:7570:37: error: 'last_boot_fops' defined but not used
> [-Werror=unused-const-variable=]
>
On Tue, 16 Jul 2024 14:13:30 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> The stub functions in kernel/numa.c belong to mm/ rather than to kernel/
>
> Signed-off-by: Mike Rapoport (Microsoft)
Makes sense + all arch specific implementations are in arch/*/mm not
On Tue, 16 Jul 2024 14:13:29 +0300
Mike Rapoport wrote:
> From: "Mike Rapoport (Microsoft)"
>
> Hi,
>
> Following the discussion about handling of CXL fixed memory windows on
> arm64 [1] I decided to bite the bullet and move numa_memblks from x86 to
> the generic code so they will be
Hi,
On Thu, 18 Jul 2024, zhangyongde.zyd wrote:
> From: Wardenjohn
>
> One system may contains more than one livepatch module. We can see
> which patch is enabled. If some patches applied to one system
> modifing the same function, livepatch will use the function enabled
> on top of the
On Fri, Jul 19, 2024 at 11:40 AM Peng Fan (OSS) wrote:
>
> The i.MX7ULP Cortex-A7 is under control of Cortex-M4. The i.MX7ULP Linux
> poweroff and restart rely on rpmsg driver to send a message to Cortex-M4
> firmware. Then Cortex-A7 could poweroff or restart by Cortex-M4 to
> configure the
On Fri, Jul 19, 2024 at 11:27 AM Peng Fan (OSS) wrote:
>
> This patchset is to upstream a few patches that in NXP downstream for
> quite sometime. For patches directly cherry-picked from NXP downstream,
> I keep the R-b tags.
>
> Patch 1 is a minor fix to DDR alias.
> Patch 2 was sent out before,
On 7/12/2024 11:34 AM, Peng Fan (OSS) wrote:
From: Peng Fan
If there is a resource table device tree node, use the address as
the resource table address, otherwise use the address(where
.resource_table section loaded) inside the Cortex-M elf file.
And there is an update in NXP SDK that
On Thu, Jul 18, 2024 at 04:46:17PM -0500, Samuel Holland wrote:
> On 2024-07-16 6:13 AM, Mike Rapoport wrote:
> > From: "Mike Rapoport (Microsoft)"
> >
> > Move code dealing with numa_distance array from arch/x86 to
> > mm/numa_memblks.c
> >
> > This code will be later reused by arch_numa.
> >
> Subject: Re: [PATCH 3/6] remoteproc: imx_rproc: initialize workqueue
> earlier
>
> On Fri, Jul 12, 2024 at 04:34:56PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Initialize workqueue before requesting mailbox channel, otherwise if
> > mailbox in
> Subject: Re: [PATCH 1/6] remoteproc: imx_rproc: correct ddr alias for
> i.MX8M
>
> Good morning,
>
> On Fri, Jul 12, 2024 at 04:34:54PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > The DDR Alias address should be 0x4000 according to RM
On 7/12/2024 11:34 AM, Peng Fan (OSS) wrote:
From: Peng Fan
Merge contiguous TCML/U regions into one to avoid load elf files which
has large sections failure.
Signed-off-by: Peng Fan
---
Reviewed-by: Iuliana Prodan
Thanks,
Iulia
drivers/remoteproc/imx_rproc.c | 18
> Subject: Re: [PATCH 5/6] remoteproc: imx_rproc: allow tx_block to be
> set
>
> On Fri, Jul 12, 2024 at 04:34:58PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Current tx_block is set to true, but there is case that no need to
> > wait res
> Subject: Re: [PATCH 4/6] remoteproc: imx_rproc: merge TCML/U
>
> On Fri, Jul 12, 2024 at 04:34:57PM +0800, Peng Fan (OSS) wrote:
> > From: Peng Fan
> >
> > Merge contiguous TCML/U regions into one to avoid load elf files
> which
> > has large sections fail
On Fri, Jul 19, 2024 at 09:02:29AM +0800, Jason Wang wrote:
> On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote:
> >
> > On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin wrote:
> > >
> > > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote:
> > > > On Wed, Jul 10, 2024 at 11:03 AM Jason
On Wed, Jul 17, 2024 at 2:53 PM Jason Wang wrote:
>
> On Wed, Jul 17, 2024 at 2:00 PM Michael S. Tsirkin wrote:
> >
> > On Wed, Jul 17, 2024 at 09:19:02AM +0800, Jason Wang wrote:
> > > On Wed, Jul 10, 2024 at 11:03 AM Jason Wang wrote:
> > > >
> > > > On Tue, Jul 9, 2024 at 9:28 PM Michael S.
1 - 100 of 2412006 matches
Mail list logo
