* Russell King - ARM Linux [off-list ref] wrote:

On Thu, Jan 14, 2016 at 12:23:54PM +0100, Ingo Molnar wrote:

quoted

* Keerthy [off-list ref] wrote:

quoted

I tried to simulate the issue.

In the probe function of drivers/thermal/ti-soc-thermal/ti-bandgap.c
ti_bandgap_probe i call

orderly_poweroff(true);

This is while driver probes are still on going. I observe that
ret = run_cmd(poweroff_cmd);

ret is a non-zero value and we enter the if condition:

Even after the

emergency_sync();
kernel_power_off();

calls

the console remained active in weird state.

Now _that_ is clearly an architecture bug that should not be papered over ...

No, it's not an architecture bug - it's a platform bug. [...]

It's an 'architecture bug' in Linux kernel speak: all stuff that is traditionally 
under arch/*. The 'arch' in that directory name derives from 'architecture'.

kernel_power_off() is a traditionally architecture level (not core kernel level 
and not driver level) code.

[...] The ARM architecture has no standard way to control CPU reset or system 
power, all that is up to the platform.

... and platform code is typically part of arch/ as well.

FYI, you are making an unnecessarily obtuse argument by insisting on the 
architecture != platform triviality and you also injected an uncalled for 
patronizing tone into this discussion by pretending that I don't know that 
distinction. It's sad.

quoted

If kernel_power_off() is called then the system should power off. No ifs and 
whens.

There definitely are ifs and whens.  Only if the platform has support, and when 
that support works.

And that is precisely what I meant: in a correctly working kernel, with correctly 
working hardware, in a correctly working universe, the core kernel expects 
kernel_power_off() to never 'fail'.

As the name suggests.

Yes, bugs in user-space, kernel-space, hardware and designed buggy hardware might 
prevent a reboot - as usual.

I.e. I NAK this patch from a core kernel perspective, we don't add such 
workarounds without a lot more information about why it's the right thing to do.

Thanks,

	Ingo