On Wed, 4 Dec 2024 16:41:33 +0100
Andrew Lunn wrote:
> On Wed, Dec 04, 2024 at 09:22:32AM +0100, Maxime Chevallier wrote:
> > Hello Andrew,
> >
> > On Wed, 4 Dec 2024 03:15:52 +0100
> > Andrew Lunn wrote:
> >
> > > > +static bool phy_interface_mode_is_reduced(phy_interface_t interface)
> > >
On Wed, Dec 4, 2024 at 10:33 PM Ian Rogers wrote:
>
> On Wed, Dec 4, 2024 at 9:47 PM Namhyung Kim wrote:
> >
> > Hi Ian,
> >
> > On Wed, Dec 04, 2024 at 06:23:05PM -0800, Ian Rogers wrote:
> > > The refactoring of tool PMU events to have a PMU then adding the expr
> > > literals to the tool PMU m
On Wed, Dec 4, 2024 at 9:47 PM Namhyung Kim wrote:
>
> Hi Ian,
>
> On Wed, Dec 04, 2024 at 06:23:05PM -0800, Ian Rogers wrote:
> > The refactoring of tool PMU events to have a PMU then adding the expr
> > literals to the tool PMU made it so that the literal system_tsc_freq
> > was only supported o
Hi Ian,
On Wed, Dec 04, 2024 at 06:23:05PM -0800, Ian Rogers wrote:
> The refactoring of tool PMU events to have a PMU then adding the expr
> literals to the tool PMU made it so that the literal system_tsc_freq
> was only supported on x86. Update the test expectations to match -
> namely the parsi
The refactoring of tool PMU events to have a PMU then adding the expr
literals to the tool PMU made it so that the literal system_tsc_freq
was only supported on x86. Update the test expectations to match -
namely the parsing is x86 specific and only yields a non-zero value on
Intel.
Fixes: 609aa26
On Wed, 2024-12-04 at 17:57 +0100, Michal Suchánek wrote:
> On Mon, Dec 02, 2024 at 08:40:05PM -0800, Haren Myneni wrote:
> > On Wed, 2024-11-27 at 10:11 +0100, Michal Suchánek wrote:
> > > On Tue, Nov 26, 2024 at 12:40:20PM -0800, Haren Myneni wrote:
> > > > On Wed, 2024-11-27 at 00:42 +0530, Mahe
Hello,
On Fri, Nov 29, 2024 at 04:13:53PM +0530, Atharva Tiwari wrote:
> - Added a null check for 'o' before copying the last OPTION_END in
> options__order function to prevent potential uninitialized usage.
> - Refactored the parse_long_opt function for improved readability by aligning
> functi
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
From: Michael Ellerman
[ Upstream commit cf89c9434af122f28a3552e6f9cc5158c33ce50a ]
On some powermacs `escc` nodes are missing `#size-cells` properties,
which is deprecated and now triggers a warning at boot since commit
045b14ca5c36 ("of: WARN on deprecated #address-cells/#size-cells
handling")
Hi Christophe,
kernel test robot noticed the following build warnings:
[auto build test WARNING on powerpc/next]
[also build test WARNING on powerpc/fixes linus/master v6.13-rc1 next-20241204]
[cannot apply to tip/x86/core]
[If your patch is applied to the wrong git tree, kindly drop us a note
Thomas,
> Using the macro saves some lines of code and prepares the attributes for
> the general constifications of struct bin_attributes.
>
> While at it also constify the callback parameters.
Looks OK to me.
Reviewed-by: Martin K. Petersen
--
Martin K. Petersen Oracle Linux Engineeri
On Mon, Dec 02, 2024 at 08:40:05PM -0800, Haren Myneni wrote:
> On Wed, 2024-11-27 at 10:11 +0100, Michal Suchánek wrote:
> > On Tue, Nov 26, 2024 at 12:40:20PM -0800, Haren Myneni wrote:
> > > On Wed, 2024-11-27 at 00:42 +0530, Mahesh J Salgaonkar wrote:
> > > > On 2024-11-23 21:20:39 Sat, Haren M
On Wed, Dec 04, 2024 at 09:22:32AM +0100, Maxime Chevallier wrote:
> Hello Andrew,
>
> On Wed, 4 Dec 2024 03:15:52 +0100
> Andrew Lunn wrote:
>
> > > +static bool phy_interface_mode_is_reduced(phy_interface_t interface)
> > > +{
> > > + return phy_interface_mode_is_rgmii(interface) ||
> > > +
Consolidate the machine_kexec_mask_interrupts implementation into a common
function located in a new file: kernel/irq/kexec.c. This removes duplicate
implementations from architecture-specific files in arch/arm, arch/arm64,
arch/powerpc, and arch/riscv, reducing code duplication and improving
maint
During machine kexec, the function machine_kexec_mask_interrupts() is
responsible for disabling or masking all interrupts. While the irq_disable
hook ensures that an already-disabled IRQ is not disabled again, the
current implementation unconditionally invokes the irq_mask() function for
every inte
This patch series focuses on improving the machine_kexec_mask_interrupts()
function by consolidating its implementation and optimizing its behavior to
avoid redundant interrupt masking.
Patch Summary:
[PATCH v6 1/2] Move machine_kexec_mask_interrupts() to kernel/irq/kexec.c,
removin
On Tue, Dec 03, 2024 at 08:44:50PM +0100, Christophe Leroy wrote:
> Add support for 'bla' instruction.
>
> This is done by 'flagging' the address as an absolute address so that
> arch_jump_destination() can calculate it as expected. Because code is
> _always_ 4 bytes aligned, use bit 30 as flag.
On Wed, Dec 04 2024 at 11:40, Eliav Farber wrote:
> I'm just waiting for a reply if the new configuration option should be
> placed inside or after the following section:
I think you got one yesterday :)
On 12/4/2024 1:02 PM, Jiri Slaby wrote:
>> +
>> +config GENERIC_IRQ_KEXEC_CLEAR_VM_FORWARD
>> + bool "Clear forwarded VM interrupts during kexec"
>> + default n
>> + help
>> + When enabled, this option allows the kernel to clear the active state
>> + of interrupts that are f
A parked CPU is considered to be flagged as unsuitable to process
workload at the moment, but might be become usable anytime. Depending on
the necessity for additional computation power and/or available capacity
of the underlying hardware.
A scheduler group is considered to be parked if it only co
Adding a new scheduler group type which allows to remove all tasks
from certain CPUs through load balancing can help in scenarios where
such CPUs are currently unfavorable to use, for example in a
virtualized environment.
Functionally, this works as intended. The question would be, if this
could
In this simplified example, vertical low CPUs are parked generally.
This will later be adjusted by making the parked state dependent
on the overall utilization on the underlying hypervisor.
Vertical lows are always bound to the highest CPU IDs. This implies that
the three types of vertically pol
On 04.12.24 11:04, Oscar Salvador wrote:
On Wed, Dec 04, 2024 at 10:28:39AM +0100, David Hildenbrand wrote:
On 04.12.24 10:15, Oscar Salvador wrote:
On Wed, Dec 04, 2024 at 10:03:28AM +0100, Vlastimil Babka wrote:
On 12/4/24 09:59, Oscar Salvador wrote:
On Tue, Dec 03, 2024 at 08:19:02PM +010
On 30. 11. 24, 21:11, Eliav Farber wrote:
Consolidate the machine_kexec_mask_interrupts implementation into a common
function located in a new file: kernel/irq/kexec.c. This removes duplicate
implementations from architecture-specific files in arch/arm, arch/arm64,
arch/powerpc, and arch/riscv, r
On Wed, Dec 04, 2024 at 10:28:39AM +0100, David Hildenbrand wrote:
> On 04.12.24 10:15, Oscar Salvador wrote:
> > On Wed, Dec 04, 2024 at 10:03:28AM +0100, Vlastimil Babka wrote:
> > > On 12/4/24 09:59, Oscar Salvador wrote:
> > > > On Tue, Dec 03, 2024 at 08:19:02PM +0100, David Hildenbrand wrote:
On Wed, Dec 04, 2024 at 10:03:28AM +0100, Vlastimil Babka wrote:
> On 12/4/24 09:59, Oscar Salvador wrote:
> > On Tue, Dec 03, 2024 at 08:19:02PM +0100, David Hildenbrand wrote:
> >> It was always set using "GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL",
> >> and I removed the same flag combinati
On 04.12.24 10:15, Oscar Salvador wrote:
On Wed, Dec 04, 2024 at 10:03:28AM +0100, Vlastimil Babka wrote:
On 12/4/24 09:59, Oscar Salvador wrote:
On Tue, Dec 03, 2024 at 08:19:02PM +0100, David Hildenbrand wrote:
It was always set using "GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL",
and I r
On Tue, Dec 03, 2024 at 08:19:02PM +0100, David Hildenbrand wrote:
> It was always set using "GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL",
> and I removed the same flag combination in #2 from memory offline code, and
> we do have the exact same thing in do_migrate_range() in
> mm/memory_hotplug
On Tue, Dec 03, 2024 at 10:47:31AM +0100, David Hildenbrand wrote:
> In the __GFP_COMP case, we already pass the gfp_flags to
> prep_new_page()->post_alloc_hook(). However, in the !__GFP_COMP case, we
> essentially pass only hardcoded __GFP_MOVABLE to post_alloc_hook(),
> preventing some action mod
On 12/4/24 09:59, Oscar Salvador wrote:
> On Tue, Dec 03, 2024 at 08:19:02PM +0100, David Hildenbrand wrote:
>> It was always set using "GFP_USER | __GFP_MOVABLE | __GFP_RETRY_MAYFAIL",
>> and I removed the same flag combination in #2 from memory offline code, and
>> we do have the exact same thing
On Tue, Dec 03, 2024 at 10:47:30AM +0100, David Hildenbrand wrote:
> It's all a bit complicated for alloc_contig_range(). For example, we don't
> support many flags, so let's start bailing out on unsupported
> ones -- ignoring the placement hints, as we are already given the range
> to allocate.
>
On 12/3/24 20:19, David Hildenbrand wrote:
> On 03.12.24 15:24, Vlastimil Babka wrote:
>> On 12/3/24 15:12, David Hildenbrand wrote:
>>> On 03.12.24 14:55, Vlastimil Babka wrote:
>>> likely the thing we are assuming here is that we are migrating a page, and
>>> usually, these are user allocation (e
Hello Andrew,
On Wed, 4 Dec 2024 03:15:52 +0100
Andrew Lunn wrote:
> > +static bool phy_interface_mode_is_reduced(phy_interface_t interface)
> > +{
> > + return phy_interface_mode_is_rgmii(interface) ||
> > + interface == PHY_INTERFACE_MODE_RMII ||
> > + interface == PHY_INTE
The word 'accross' is wrong, so fix it.
Signed-off-by: Zhu Jun
---
tools/testing/selftests/powerpc/vphn/test-vphn.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/testing/selftests/powerpc/vphn/test-vphn.c
b/tools/testing/selftests/powerpc/vphn/test-vphn.c
index 81d30
40 matches
Mail list logo
