Re: [PATCH] fbdev/xen-fbfront: Assign fb_info->device

2024-09-10 Thread Helge Deller

On 9/10/24 04:09, Jason Andryuk wrote:

From: Jason Andryuk 

Probing xen-fbfront faults in video_is_primary_device().  The passed-in
struct device is NULL since xen-fbfront doesn't assign it and the
memory is kzalloc()-ed.  Assign fb_info->device to avoid this.

This was exposed by the conversion of fb_is_primary_device() to
video_is_primary_device() which dropped a NULL check for struct device.

Fixes: f178e96de7f0 ("arch: Remove struct fb_info from video helpers")
Reported-by: Arthur Borsboom 
Closes: 
https://lore.kernel.org/xen-devel/CALUcmUncX=lkxweisitksdy-coe8qkswhfvccneokfrkd0z...@mail.gmail.com/
Tested-by: Arthur Borsboom 
CC: sta...@vger.kernel.org
Signed-off-by: Jason Andryuk 


applied to fbdev git tree.

Thanks!
Helge




Re: [patch V4 00/37] cpu/hotplug, x86: Reworked parallel CPU bringup

2023-05-13 Thread Helge Deller

Hi Thomas,

On pátek 12. května 2023 23:06:56 CEST Thomas Gleixner wrote:

This is version 4 of the reworked parallel bringup series. Version 3 can be
found here:

https://lore.kernel.org/lkml/20230508181633.089804...@linutronix.de
...

Other than that there are no changes and the other details are all the same
as in V3 and V2.

It's also available from git:

 git://git.kernel.org/pub/scm/linux/kernel/git/tglx/devel.git hotplug


I tested your series on the parisc architecture just to make sure that it still 
works
with your patch applied.
On parisc the CPU bringup happens later in the boot process (after the 
inventory),
so your patch won't have an direct impact anyway.
But at least everything still works, incl. manual CPU enable/disable.

So, you may add
Tested-by: Helge Deller  # parisc

Thanks!
Helge



Re: [PATCH 12/30] parisc: Replace regular spinlock with spin_trylock on panic path

2022-04-28 Thread Helge Deller
On 4/28/22 00:49, Guilherme G. Piccoli wrote:
> The panic notifiers' callbacks execute in an atomic context, with
> interrupts/preemption disabled, and all CPUs not running the panic
> function are off, so it's very dangerous to wait on a regular
> spinlock, there's a risk of deadlock.
>
> This patch refactors the panic notifier of parisc/power driver
> to make use of spin_trylock - for that, we've added a second
> version of the soft-power function. Also, some comments were
> reorganized and trailing white spaces, useless header inclusion
> and blank lines were removed.
>
> Cc: Helge Deller 
> Cc: "James E.J. Bottomley" 
> Signed-off-by: Guilherme G. Piccoli 

You may add:
Acked-by: Helge Deller  # parisc

Helge


> ---
>  arch/parisc/include/asm/pdc.h |  1 +
>  arch/parisc/kernel/firmware.c | 27 +++
>  drivers/parisc/power.c| 17 ++---
>  3 files changed, 34 insertions(+), 11 deletions(-)
>
> diff --git a/arch/parisc/include/asm/pdc.h b/arch/parisc/include/asm/pdc.h
> index b643092d4b98..7a106008e258 100644
> --- a/arch/parisc/include/asm/pdc.h
> +++ b/arch/parisc/include/asm/pdc.h
> @@ -83,6 +83,7 @@ int pdc_do_firm_test_reset(unsigned long ftc_bitmap);
>  int pdc_do_reset(void);
>  int pdc_soft_power_info(unsigned long *power_reg);
>  int pdc_soft_power_button(int sw_control);
> +int pdc_soft_power_button_panic(int sw_control);
>  void pdc_io_reset(void);
>  void pdc_io_reset_devices(void);
>  int pdc_iodc_getc(void);
> diff --git a/arch/parisc/kernel/firmware.c b/arch/parisc/kernel/firmware.c
> index 6a7e315bcc2e..0e2f70b592f4 100644
> --- a/arch/parisc/kernel/firmware.c
> +++ b/arch/parisc/kernel/firmware.c
> @@ -1232,15 +1232,18 @@ int __init pdc_soft_power_info(unsigned long 
> *power_reg)
>  }
>
>  /*
> - * pdc_soft_power_button - Control the soft power button behaviour
> - * @sw_control: 0 for hardware control, 1 for software control
> + * pdc_soft_power_button{_panic} - Control the soft power button behaviour
> + * @sw_control: 0 for hardware control, 1 for software control
>   *
>   *
>   * This PDC function places the soft power button under software or
>   * hardware control.
> - * Under software control the OS may control to when to allow to shut
> - * down the system. Under hardware control pressing the power button
> + * Under software control the OS may control to when to allow to shut
> + * down the system. Under hardware control pressing the power button
>   * powers off the system immediately.
> + *
> + * The _panic version relies in spin_trylock to prevent deadlock
> + * on panic path.
>   */
>  int pdc_soft_power_button(int sw_control)
>  {
> @@ -1254,6 +1257,22 @@ int pdc_soft_power_button(int sw_control)
>   return retval;
>  }
>
> +int pdc_soft_power_button_panic(int sw_control)
> +{
> + int retval;
> + unsigned long flags;
> +
> + if (!spin_trylock_irqsave(&pdc_lock, flags)) {
> + pr_emerg("Couldn't enable soft power button\n");
> + return -EBUSY; /* ignored by the panic notifier */
> + }
> +
> + retval = mem_pdc_call(PDC_SOFT_POWER, PDC_SOFT_POWER_ENABLE, 
> __pa(pdc_result), sw_control);
> + spin_unlock_irqrestore(&pdc_lock, flags);
> +
> + return retval;
> +}
> +
>  /*
>   * pdc_io_reset - Hack to avoid overlapping range registers of Bridges 
> devices.
>   * Primarily a problem on T600 (which parisc-linux doesn't support) but
> diff --git a/drivers/parisc/power.c b/drivers/parisc/power.c
> index 456776bd8ee6..8512884de2cf 100644
> --- a/drivers/parisc/power.c
> +++ b/drivers/parisc/power.c
> @@ -37,7 +37,6 @@
>  #include 
>  #include 
>  #include 
> -#include 
>  #include 
>  #include 
>  #include 
> @@ -175,16 +174,21 @@ static void powerfail_interrupt(int code, void *x)
>
>
>
> -/* parisc_panic_event() is called by the panic handler.
> - * As soon as a panic occurs, our tasklets above will not be
> - * executed any longer. This function then re-enables the
> - * soft-power switch and allows the user to switch off the system
> +/*
> + * parisc_panic_event() is called by the panic handler.
> + *
> + * As soon as a panic occurs, our tasklets above will not
> + * be executed any longer. This function then re-enables
> + * the soft-power switch and allows the user to switch off
> + * the system. We rely in pdc_soft_power_button_panic()
> + * since this version spin_trylocks (instead of regular
> + * spinlock), preventing deadlocks on panic path.
>   */
>  static int parisc_panic_event(struct notifier_block *this,
>   unsigned long event, void *ptr)
>  {
>   /* re-enable the soft-power switch */
> - pdc_soft_power_button(0);
> + pdc_soft_power_button_panic(0);
>   return NOTIFY_DONE;
>  }
>
> @@ -193,7 +197,6 @@ static struct notifier_block parisc_panic_block = {
>   .priority   = INT_MAX,
>  };
>
> -
>  static int __init power_init(void)
>  {
>   unsigned long ret;




Re: [PATCH v6 00/21] Introduce power-off+restart call chain API

2022-02-16 Thread Helge Deller
On 2/16/22 13:25, Rafael J. Wysocki wrote:
> 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 for power-off.
>>>
>>> Solution
>>> 
>>>
>>> Introduce new API that provides both restart and power-off call chains.
>>>
>>> Why combine restart with power-off? Because drivers often do both.
>>> More practical to have API that provides both under the same roof.
>>>
>>> The new API is designed with simplicity and extensibility in mind.
>>> It's built upon the existing restart and reboot APIs. The simplicity
>>> is in new helper functions that are convenient for drivers. The
>>> extensibility is in the design that doesn't hardcode callback
>>> arguments, making easy to add new parameters and remove old.
>>>
>>> This is a third attempt to introduce the new API. First was made by
>>> Guenter Roeck back in 2014, second was made by Thierry Reding in 2017.
>>> In fact the work didn't stop and recently arm_pm_restart() was removed
>>> from v5.14 kernel, which was a part of preparatory work started by
>>> Guenter Roeck. I took into account experience and ideas from the
>>> previous attempts, extended and polished them.
>>
>>
>> Rafael and all, do you see anything critical that needs to be improved
>> in this v6?
>>
>> Will be great if you could take this patchset via the power tree if it
>> looks okay, or give an ack.
>
> I need some more time for this, sorry.
>
> I'm a bit concerned about seeing no response to this set from anyone.
>
> It looks like multiple platforms may be affected by it in principle,
> so doesn't anyone care?

I did looked into the whole patch set after applying it locally.

While I agree a new combined API is good, and the beginning looked promising,
after some time I started to ask myself if the whole infrastructure might
be a little overdesigned.

Anyway, I tested it and it works for me on parisc.
And it's probably better than what we have today.

Helge



Re: [PATCH v2 16/45] parisc: Use do_kernel_power_off()

2021-10-27 Thread Helge Deller
On 10/27/21 23:16, Dmitry Osipenko wrote:
> Kernel now supports chained power-off handlers. Use do_kernel_power_off()
> that invokes chained power-off handlers. It also invokes legacy
> pm_power_off() for now, which will be removed once all drivers will
> be converted to the new power-off API.
>
> Signed-off-by: Dmitry Osipenko 

Acked-by: Helge Deller  # parisc



> ---
>  arch/parisc/kernel/process.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/arch/parisc/kernel/process.c b/arch/parisc/kernel/process.c
> index ea3d83b6fb62..928201b1f58f 100644
> --- a/arch/parisc/kernel/process.c
> +++ b/arch/parisc/kernel/process.c
> @@ -26,6 +26,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -114,8 +115,7 @@ void machine_power_off(void)
>   pdc_chassis_send_status(PDC_CHASSIS_DIRECT_SHUTDOWN);
>
>   /* ipmi_poweroff may have been installed. */
> - if (pm_power_off)
> - pm_power_off();
> + do_kernel_power_off();
>
>   /* It seems we have no way to power the system off via
>* software. The user has to press the button himself. */
>




Re: [PATCH v2 1/1] kernel.h: Split out panic and oops helpers

2021-04-10 Thread Helge Deller

On 4/9/21 12:02 PM, Andy Shevchenko wrote:

kernel.h is being used as a dump for all kinds of stuff for a long time.
Here is the attempt to start cleaning it up by splitting out panic and
oops helpers.

There are several purposes of doing this:
- dropping dependency in bug.h
- dropping a loop by moving out panic_notifier.h
- unload kernel.h from something which has its own domain

At the same time convert users tree-wide to use new headers, although
for the time being include new header back to kernel.h to avoid twisted
indirected includes for existing users.

Signed-off-by: Andy Shevchenko 
Reviewed-by: Bjorn Andersson 
Acked-by: Mike Rapoport 
Acked-by: Corey Minyard 
Acked-by: Christian Brauner 
Acked-by: Arnd Bergmann 
Acked-by: Kees Cook 
Acked-by: Wei Liu 
Acked-by: Rasmus Villemoes 
Signed-off-by: Andrew Morton 


Acked-by: Helge Deller  # parisc

Helge