On Tue, Nov 28, 2017 at 10:43 AM, Juergen Gross wrote:
> In the non-EFI boot path the ACPI RSDP table is currently found via
> either EBDA or by searching through low memory for the RSDP magic.
> This requires the RSDP to be located in the first 1MB of physical
> memory. Xen PVH guests, however, g
On Mon, May 20, 2019 at 4:48 PM Mauro Carvalho Chehab
wrote:
>
> Mostly due to x86 and acpi conversion, several documentation
> links are still pointing to the old file. Fix them.
>
> Signed-off-by: Mauro Carvalho Chehab
For the ACPI part:
Acked-by: Ra
On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
wrote:
>
> %pS and %ps are now the preferred conversion specifiers to print function
> %names. The functionality is equivalent; remove the old, deprecated %pF
> %and %pf support.
Are %pF and %pf really not used any more in the kernel?
If that is not t
following command:
>
> git grep -l '%p[fF]' | grep -v '^\(tools\|Documentation\)/' | \
> while read i; do perl -i -pe 's/%pf/%ps/g; s/%pF/%pS/g;' $i; done
>
> And verifying the result.
>
> Signed-off-by: Sakari Ailus
Acked-by: Rafa
On Mon, Mar 25, 2019 at 10:30 AM Rafael J. Wysocki wrote:
>
> On Fri, Mar 22, 2019 at 2:21 PM Sakari Ailus
> wrote:
> >
> > %pS and %ps are now the preferred conversion specifiers to print function
> > %names. The functionality is equivalent; remove the old, deprecat
> Cc: Ingo Molnar
> Cc: jpoim...@redhat.com
> Cc: Juergen Gross
> Cc: Len Brown
> Cc: Linus Torvalds
> Cc: linux-ker...@vger.kernel.org
> Cc: linux...@vger.kernel.org
> Cc: Borislav Petkov
> Cc: mi...@redhat.com
> Cc: Pavel Machek
> Cc: Peter Zijlstra
> Cc:
sn't creating
>>> an acpi_processor for non-dom0 CPUs.
>>>
>>> Signed-off-by: Joao Martins
>>
>> Reviewed-by: Boris Ostrovsky
>>
> Thanks!
>
> I suppose what's remaining is review (or ack) from ACPI folks on the interface
> change
On Wed, Aug 15, 2018 at 8:44 AM Jan Beulich wrote:
>
> >>> On 25.06.18 at 12:17, wrote:
> > This is unnecessary and triggers a warning in the hypervisor.
> >
> > Often systems have more processor entries in their ACPI tables than are
> > actually installed/active. The ACPI_STA_DEVICE_PRESENT bit
On Fri, Aug 17, 2018 at 9:59 AM David Hildenbrand wrote:
>
> There seem to be some problems as result of 30467e0b3be ("mm, hotplug:
> fix concurrent memory hot-add deadlock"), which tried to fix a possible
> lock inversion reported and discussed in [1] due to the two locks
> a) device_lock
On Fri, Aug 17, 2018 at 10:41 AM Greg Kroah-Hartman
wrote:
>
> On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> > From: Vitaly Kuznetsov
> >
> > Well require to call add_memory()/add_memory_resource() with
> > device_hotplug_lock held, to avoid a lock inversion. Allow external
On Fri, Aug 17, 2018 at 10:56 AM David Hildenbrand wrote:
>
> On 17.08.2018 10:41, Greg Kroah-Hartman wrote:
> > On Fri, Aug 17, 2018 at 09:59:00AM +0200, David Hildenbrand wrote:
> >> From: Vitaly Kuznetsov
> >>
> >> Well require to call add_memory()/add_memory_resource() with
> >> device_hotplu
>
> Apart from that, there are not other users in the tree.
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Rashmica Gupta
> Cc: Michael Neuling
> Cc: Balbir Singh
> Cc:
(as device_hotplug_lock is never
> exported).
>
> Cc: Benjamin Herrenschmidt
> Cc: Paul Mackerras
> Cc: Michael Ellerman
> Cc: "Rafael J. Wysocki"
> Cc: Len Brown
> Cc: Greg Kroah-Hartman
> Cc: Boris Ostrovsky
> Cc: Juergen Gross
> Cc: Nathan Font
On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko
wrote:
> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki wrote:
>> On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
>> wrote:
>>> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross wrote:
>>>> On 26/01/18 19
On Thu, Feb 1, 2018 at 4:45 PM, Andy Shevchenko
wrote:
> On Thu, Feb 1, 2018 at 9:57 AM, Rafael J. Wysocki wrote:
>> On Wed, Jan 31, 2018 at 4:43 PM, Andy Shevchenko
>> wrote:
>>> On Mon, Jan 29, 2018 at 5:02 AM, Rafael J. Wysocki
>>> wrote:
>>&
+
6 files changed, 43 insertions(+), 4 deletions(-)
The series is fine by me:
Acked-by: Rafael J. Wysocki
___
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
On Monday, November 19, 2018 11:16:16 AM CET David Hildenbrand wrote:
> The content of pages that are marked PG_offline is not of interest
> (e.g. inflated by a balloon driver), let's skip these pages.
>
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> Cc: Len
On Monday, November 19, 2018 11:16:15 AM CET David Hildenbrand wrote:
> Let's use pfn_to_online_page() instead of pfn_to_page() when checking
> for saveable pages to not save/restore offline memory sections.
>
> Cc: "Rafael J. Wysocki"
> Cc: Pavel Machek
> C
On Fri, Jan 26, 2018 at 7:08 PM, Andy Shevchenko
wrote:
> On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross wrote:
>> Add a function to get the address of the RSDP table. Per default use a
>> __weak annotated function being a nop.
>
> The problem with weak functions that we can't have more than one
On Sun, Jan 28, 2018 at 4:04 PM, Andy Shevchenko
wrote:
> On Fri, Jan 26, 2018 at 8:21 PM, Juergen Gross wrote:
>> On 26/01/18 19:08, Andy Shevchenko wrote:
>>> On Thu, Jan 25, 2018 at 4:36 PM, Juergen Gross wrote:
Add a function to get the address of the RSDP table. Per default use a
On Mon, Nov 23, 2020 at 4:58 PM James Bottomley
wrote:
>
> On Mon, 2020-11-23 at 15:19 +0100, Miguel Ojeda wrote:
> > On Sun, Nov 22, 2020 at 11:36 PM James Bottomley
> > wrote:
[cut]
> >
> > Maintainers routinely review 1-line trivial patches, not to mention
> > internal API changes, etc.
>
>
On Mon, Jan 13, 2020 at 12:43 PM Singh, Balbir wrote:
>
> On Mon, 2020-01-13 at 11:16 +0100, Peter Zijlstra wrote:
> > On Fri, Jan 10, 2020 at 07:35:20AM -0800, Eduardo Valentin wrote:
> > > Hey Peter,
> > >
> > > On Wed, Jan 08, 2020 at 11:50:11AM +0100, Peter Zijlstra wrote:
> > > > On Tue, Jan
On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra wrote:
>
> On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> > For your original comment, just wanted to clarify the following:
> >
> > 1. After hibernation, the machine can be resumed on a different but
> > compatible
> > host (these
On Mon, Jan 13, 2020 at 10:50 PM Rafael J. Wysocki wrote:
>
> On Mon, Jan 13, 2020 at 1:43 PM Peter Zijlstra wrote:
> >
> > On Mon, Jan 13, 2020 at 11:43:18AM +, Singh, Balbir wrote:
> > > For your original comment, just wanted to clarify the following:
> >
On Thu, Jan 28, 2021 at 8:21 AM Chaitanya Kulkarni
wrote:
>
Please explain in the changelog why making this change is a good idea.
> Signed-off-by: Chaitanya Kulkarni
> ---
> kernel/power/swap.c | 7 +++
> 1 file changed, 3 insertions(+), 4 deletions(-)
>
> diff --git a/kernel/power/swap.c
From: Rafael J. Wysocki
The ACPI_DEBUG_PRINT() macro is used in a few places in
xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printing debug
messages, but that is questionable, because that macro belongs to
ACPICA and it should not be used elsewhere. In addition,
ACPI_DEBUG_PRINT
On Fri, Jul 31, 2020 at 4:14 PM Boris Ostrovsky
wrote:
>
> On 7/30/20 7:06 PM, Anchal Agarwal wrote:
> > On Mon, Jul 27, 2020 at 06:08:29PM -0400, Boris Ostrovsky wrote:
> >> CAUTION: This email originated from outside of the organization. Do not
> >> click links or open attachments unless you ca
On Fri, Aug 28, 2020 at 8:26 PM Anchal Agarwal wrote:
>
> On Fri, Aug 21, 2020 at 10:22:43PM +, Anchal Agarwal wrote:
> > Hello,
> > This series fixes PM hibernation for hvm guests running on xen hypervisor.
> > The running guest could now be hibernated and resumed successfully at a
> > later
On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
wrote:
>
> Add sanity check which ensures that there are no two restart handlers
> registered using the same priority. This requirement will become mandatory
> once all drivers will be converted to the new API and such errors will be
> fixed.
>
> Sig
On Thu, Apr 14, 2022 at 12:24 AM Dmitry Osipenko
wrote:
>
> On 4/13/22 21:48, Rafael J. Wysocki wrote:
> > On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
> > wrote:
> >>
> >> Add sanity check which ensures that there are no two restart handlers
> >
Honestly, I would prefer this to be split so as to make it easier to
review if nothing else.
On Tue, Apr 12, 2022 at 1:39 AM Dmitry Osipenko
wrote:
>
> SoC platforms often have multiple ways of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a
On Mon, Apr 18, 2022 at 3:29 AM Dmitry Osipenko
wrote:
>
> On 4/14/22 14:19, Rafael J. Wysocki wrote:
> > On Thu, Apr 14, 2022 at 12:24 AM Dmitry Osipenko
> > wrote:
> >>
> >> On 4/13/22 21:48, Rafael J. Wysocki wrote:
> >>> On Tue, Apr
On Mon, Apr 18, 2022 at 3:44 AM Dmitry Osipenko
wrote:
>
> On 4/15/22 21:14, Rafael J. Wysocki wrote:
> > Honestly, I would prefer this to be split so as to make it easier to
> > review if nothing else.
>
> I'll try to split it in v8.
>
> > On Tue, A
On Wed, Oct 27, 2021 at 11:18 PM Dmitry Osipenko wrote:
>
> SoC platforms often have multiple options of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a single option. Add combined power-off+restart handler call chain API,
> which is inspired
On Wed, Oct 27, 2021 at 11:18 PM Dmitry Osipenko wrote:
>
> SoC platforms often have multiple options of how to perform system's
> power-off and restart operations. Meanwhile today's kernel is limited to
> a single option. Add combined power-off+restart handler call chain API,
> which is inspired
On Tue, Feb 15, 2022 at 11:00 PM Dmitry Osipenko wrote:
>
> 31.01.2022 02:36, Dmitry Osipenko пишет:
> > Problem
> > ---
> >
> > SoC devices require power-off call chaining functionality from kernel.
> > We have a widely used restart chaining provided by restart notifier API,
> > but nothing f
On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross wrote:
>
> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> > On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
> >>
> >> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> >> X
On Tue, Jan 17, 2023 at 4:32 PM Juergen Gross wrote:
>
> On 17.01.23 15:09, Rafael J. Wysocki wrote:
> > On Mon, Jan 16, 2023 at 7:45 AM Juergen Gross wrote:
> >>
> >> On 13.01.23 20:40, Rafael J. Wysocki wrote:
> >>> On Fri, Jan 13, 2023 at 3:06 PM
On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
>
> Make cpuidle_enter_state() consistent with the s2idle variant and
> verify ->enter() always returns with interrupts disabled.
>
> Signed-off-by: Peter Zijlstra (Intel)
> ---
> drivers/cpuidle/cpuidle.c | 10 +-
> 1 file changed,
On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
>
> cpuidle_state::enter() methods should be IRQ invariant
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/cpuidle/poll_state.c |4 +++-
> 1 file changed, 3 inse
On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
>
> All the idle routines are called with RCU disabled, as such there must
> not be any tracing inside.
>
> Signed-off-by: Peter Zijlstra (Intel)
This actually does some additional code duplication cleanup which
would be good to mention in the
On Wed, Jun 8, 2022 at 4:46 PM Peter Zijlstra wrote:
>
> The __cpuidle functions will become a noinstr class, as such they need
> explicit annotations.
>
> Signed-off-by: Peter Zijlstra (Intel)
Reviewed-by: Rafael J. Wysocki
> ---
> drivers/cpuidle/poll_state.c |
at
> architectures that can idle with IRQs disabled end up doing a
> pointless 'enable-disable' dance.
>
> Therefore, push this IRQ disabling into the idle function, meaning
> that those architectures can avoid the pointless IRQ state flipping.
>
> Signed-off-by: Pet
: warning: objtool: acpi_idle_enter+0x115: call to
> acpi_idle_fallback_to_c1.isra.0() leaves .noinstr.text section
>
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
> ---
> arch/x86/include/asm/shared/io.h |4 ++--
> drivers/acpi/processor_idle.c
On Fri, Jul 15, 2022 at 4:25 PM Juergen Gross wrote:
>
> There are several MTRR functions which also do PAT handling. In order
> to support PAT handling without MTRR in the future, add some wrappers
> for those functions.
>
> Cc: # 5.17
> Fixes: bdd8b6c98239 ("drm/i915: replace X86_FEATURE_PAT wi
On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
wrote:
>
> On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. McKenney wrote:
> > On Mon, Jul 25, 2022 at 12:43:06PM -0700, Michel Lespinasse wrote:
> > > On Wed, Jun 08, 2022 at 04:27:27PM +0200, Peter Zijlstra wrote:
> > > > Commit c227233ad64c (
On Sat, Jul 30, 2022 at 11:48 AM Michel Lespinasse
wrote:
>
> On Fri, Jul 29, 2022 at 04:59:50PM +0200, Rafael J. Wysocki wrote:
> > On Fri, Jul 29, 2022 at 12:25 PM Michel Lespinasse
> > wrote:
> > >
> > > On Thu, Jul 28, 2022 at 10:20:53AM -0700, Paul E. Mc
On Fri, Mar 17, 2023 at 1:42 PM Juergen Gross wrote:
>
> On 16.03.23 17:42, Roger Pau Monne wrote:
> > In ACPI systems, the OS can direct power management, as opposed to the
> > firmware. This OS-directed Power Management is called OSPM. Part of
> > telling the firmware that the OS going to dire
On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne wrote:
>
> In ACPI systems, the OS can direct power management, as opposed to the
> firmware. This OS-directed Power Management is called OSPM. Part of
> telling the firmware that the OS going to direct power management is
> making ACPI "_PDC" (Pro
On Tue, Mar 21, 2023 at 3:02 PM Roger Pau Monné wrote:
>
> On Tue, Mar 21, 2023 at 02:47:46PM +0100, Rafael J. Wysocki wrote:
> > On Thu, Mar 16, 2023 at 5:43 PM Roger Pau Monne
> > wrote:
> > >
> > > In ACPI systems, the OS can direct power management, as
On Wed, Mar 22, 2023 at 12:13 PM Roger Pau Monne wrote:
>
> In ACPI systems, the OS can direct power management, as opposed to the
> firmware. This OS-directed Power Management is called OSPM. Part of
> telling the firmware that the OS going to direct power management is
> making ACPI "_PDC" (Pr
álvez (For ipack)
> Reviewed-by: Tom Rix (For fpga)
> Acked-by: Geoff Levand (For ps3)
> Signed-off-by: Uwe Kleine-König
For the ACPI part:
Acked-by: Rafael J. Wysocki
> ---
>
> arch/arm/common/locomo.c | 3 +--
> arch/arm/common/sa.c
On Fri, Dec 2, 2022 at 5:37 PM Roger Pau Monné wrote:
>
> On Fri, Dec 02, 2022 at 08:17:56AM -0800, Dave Hansen wrote:
> > On 12/2/22 04:24, Roger Pau Monné wrote:
> > > On the implementation side, is the proposed approach acceptable?
> > > Mostly asking because it adds Xen conditionals to otherwi
On Thu, Dec 1, 2022 at 12:08 PM Ricardo Ribalda wrote:
>
> Add a way to let the drivers know if the processes are frozen.
>
> This is needed by drivers that are waiting for processes to end on their
> shutdown path.
>
> Convert pm_freezing into a function and export it, so it can be used by
> driv
On Fri, Jan 13, 2023 at 3:06 PM Juergen Gross wrote:
>
> Commit f1e525009493 ("x86/boot: Skip realmode init code when running as
> Xen PV guest") missed one code path accessing real_mode_header, leading
> to dereferencing NULL when suspending the system under Xen:
>
> [ 348.284004] PM: suspen
On Mon, Nov 20, 2023 at 1:20 PM David Woodhouse wrote:
>
> On Fri, 2023-10-27 at 21:14 +0200, Peter Zijlstra wrote:
> > On Fri, Oct 27, 2023 at 07:36:51PM +0100, David Woodhouse wrote:
> > > From: David Woodhouse
> > >
> > > Xen HVM guests were observed taking triple-faults when attempting to
> >
On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
wrote:
>
> Add atomic_notifier_call_chain_is_empty() that returns true if given
> atomic call chain is empty.
It would be good to mention a use case for it.
> Reviewed-by: Michał Mirosław
> Signed-off-by: Dmitry Osipenko
> ---
> include/linux/no
On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
wrote:
>
> Problem
> ---
>
> SoC devices require power-off call chaining functionality from kernel.
> We have a widely used restart chaining provided by restart notifier API,
> but nothing for power-off.
>
> Solution
>
>
> Introduce new
Hi Geert,
On Mon, May 23, 2022 at 8:08 PM Geert Uytterhoeven wrote:
>
> Hi Rafael,
>
> On Wed, May 18, 2022 at 4:46 PM Rafael J. Wysocki wrote:
> > On Tue, May 10, 2022 at 1:33 AM Dmitry Osipenko
> > wrote:
>
> > > m68k: Switch to new sys-off handler API
lly, it added a branch for no good reason.
>
> Fixes: c227233ad64c ("intel_idle: enable interrupts before C1 on Xeons")
> Signed-off-by: Peter Zijlstra (Intel)
Acked-by: Rafael J. Wysocki
And do I think correctly that this can be applied without the rest of
t
On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
>
> Typical boot time setup; no need to suffer an indirect call for that.
>
> Signed-off-by: Peter Zijlstra (Intel)
> Reviewed-by: Frederic Weisbecker
Reviewed-by: Rafael J. Wysocki
> ---
> arch/x86/ke
On Wed, Jun 8, 2022 at 5:48 PM Peter Zijlstra wrote:
>
> On Wed, Jun 08, 2022 at 05:01:05PM +0200, Rafael J. Wysocki wrote:
> > On Wed, Jun 8, 2022 at 4:47 PM Peter Zijlstra wrote:
> > >
> > > Commit c227233ad64c ("intel_idle: enable interrupts before C1 on
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> There is no need to annotate function prototypes with 'extern', it makes
> code less readable. Remove unnecessary annotations from .
>
> Signed-off-by: Dmitry Osipenko
I'm not sure that this is really useful.
Personally, I tend to respe
On Fri, Nov 26, 2021 at 7:01 PM Dmitry Osipenko wrote:
>
> Add blocking_notifier_call_chain_is_empty() that returns true if call
> chain is empty.
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/linux/notifier.h | 2 ++
> kernel/notifier.c| 14 ++
> 2 files changed, 16 in
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> Add atomic/blocking_notifier_has_unique_priority() helpers which return
> true if given handler has unique priority.
>
> Signed-off-by: Dmitry Osipenko
> ---
> include/linux/notifier.h | 5 +++
> kernel/notifier.c| 69 ++
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> Correct s/implemenations/implementations/ in .
>
> Signed-off-by: Dmitry Osipenko
This patch clearly need not be part of this series.
> ---
> include/linux/reboot.h | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git
On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko wrote:
>
> 29.11.2021 03:26, Michał Mirosław пишет:
> > On Mon, Nov 29, 2021 at 12:06:19AM +0300, Dmitry Osipenko wrote:
> >> 28.11.2021 03:28, Michał Mirosław пишет:
> >>> On Fri, Nov 26, 2021 at 09:00:41PM +0300, Dmitry Osipenko wrote:
> Add
On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
>
> Emit warning if unregister_restart_handler() fails since it never should
> fail. This will ease further API development by catching mistakes early.
>
> Signed-off-by: Dmitry Osipenko
> ---
> kernel/reboot.c | 2 +-
> 1 file changed, 1 in
On Fri, Dec 10, 2021 at 7:16 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:09, Rafael J. Wysocki пишет:
> > On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
> >>
> >> There is no need to annotate function prototypes with 'extern', it makes
>
On Fri, Dec 10, 2021 at 7:52 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:19, Rafael J. Wysocki пишет:
> ...
> >> +bool atomic_notifier_has_unique_priority(struct atomic_notifier_head *nh,
> >> + struct notifier_block *n)
> >> +{
> >> +
On Fri, Dec 10, 2021 at 7:54 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:32, Rafael J. Wysocki пишет:
> > On Fri, Nov 26, 2021 at 7:02 PM Dmitry Osipenko wrote:
> >>
> >> Emit warning if unregister_restart_handler() fails since it never should
> >> fail. Th
On Fri, Dec 10, 2021 at 8:04 PM Dmitry Osipenko wrote:
>
> 10.12.2021 21:27, Rafael J. Wysocki пишет:
> > On Mon, Nov 29, 2021 at 12:34 PM Dmitry Osipenko wrote:
> >>
> >> 29.11.2021 03:26, Michał Mirosław пишет:
> >>> On Mon, Nov 29, 2021
_hash_value;
> >>
> >> +if (!x86_platform.legacy.rtc)
> >> +return 0;
> >
> > Why does the driver core code here care about a platform/arch-specific
> > thing at all? Did you just break all other arches?
>
> This file is only compiled fo
On Sun, Feb 28, 2021 at 2:49 AM Boris Ostrovsky
wrote:
>
>
> On 2/24/21 1:47 PM, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki
> >
> > The ACPI_DEBUG_PRINT() macro is used in a few places in
> > xen-acpi-cpuhotplug.c and xen-acpi-memhotplug.c for printin
s was
> in November 2015 and has gone unnoticed for over 5 year.
>
> It is now clear that this code is of no interest to anyone and therefore
> should be removed.
>
> Signed-off-by: Boris Ostrovsky
Acked-by: Rafael J. Wysocki
Thanks for doing this!
> ---
&g
75 matches
Mail list logo