ChanServ changed the topic of #armlinux to: ARM kernel talk [Upstream kernel, find your vendor forums for questions about their kernels] | https://libera.irclog.whitequark.org/armlinux
apritzel has quit [Ping timeout: 246 seconds]
heat has joined #armlinux
jclsn has quit [Ping timeout: 256 seconds]
jclsn has joined #armlinux
heat_ has joined #armlinux
heat has quit [Ping timeout: 268 seconds]
heat_ has quit [Ping timeout: 240 seconds]
cbeznea has joined #armlinux
mvaittin has joined #armlinux
rvalue has quit [Read error: Connection reset by peer]
<monstr>
I have also sent request to linaro support and they didn't find any existing interface
<monstr>
that's why I would like to ask what interface for reporting last report reason you were talking about
Emantor has quit [Ping timeout: 240 seconds]
mripard has quit [Remote host closed the connection]
<arnd>
monstr: it's possible we never added a proper interface after all, it's just one of the things that keeps coming up. I see drivers/soc/tegra/pmc.c has a platform specific way to read the reset reason from the previous boot, but that is the other half of in the interface
<arnd>
I think Android puts it into some DT property that can be accessed through /sys/firmware/devicetree, maybe someone who is more familiar with Android can confirm
<arnd>
"git grep -i reason drivers/power/reset" shows some drivers that can set a reason
<monstr>
arnd: thanks for details
<arnd>
include/linux/reboot.h has a user interface for passing "reboot_mode" and "reboot_type", but those are a bit x86 specific and not that expressive
<monstr>
tegra is using sysfs to show that value with also an option to set it up. Show part is the same as we sent
Xogium_ has joined #armlinux
Xogium has quit [Ping timeout: 268 seconds]
Xogium_ is now known as Xogium
<arnd>
I see we have /sys/kernel/reboot/, with currently two files "cpu" and "mode", maybe we should add a "reason" file in there, with an in-kernel interface to hook that up to drivers
<monstr>
Do you know how x86 guys are doing it?
mripard has joined #armlinux
apritzel has joined #armlinux
<monstr>
For writing reason reason for us could be also the way to use nvmem drivers/power/reset/nvmem-reboot-mode.c
mripard has quit [Remote host closed the connection]
<monstr>
but that looks like it is for reporting reason for reset back to firmware not reading that last reset reason
<arnd>
But you need both, right?
<monstr>
I haven't seen any code for reporting reason from OS back to firmware. Only reading it from firmware
<monstr>
but I will double check it
<monstr>
And in /sys/kernel/reboot/ - I see 4 cpu force mode type
<monstr>
on x86
<arnd>
I'm reading drivers/power/reset/reboot-mode.c now, but don't see the user interface for that yet
<arnd>
ah, that is for setting the mode
<monstr>
OS to firmware path
<arnd>
right, or to hardware in some cases
<arnd>
/sys/kernel/reboot/ does seem to be the right place to add stuff
<monstr>
I think there are couple of levels. First level is how to report reason back from OS to firmware where there are two categories.
<monstr>
1. ultimately reason for it - certain categories
<monstr>
2. setting up the scope for reboot
<monstr>
ad 1) that what can be that reboot-mode.c driver for
<monstr>
ad 2) that's PSCI SYSTEM_RESET2 bits which I didn't see implementation for yet
<monstr>
and then second side to report it back from firmware to OS
<monstr>
and I think there is also connection to /sys/kernel/reboot/mode
<monstr>
and report back:
<arnd>
right, so /sys/kernel/reboot/mode is a way to access the global "enum reboot_mode"
<monstr>
a) sysfs interface - private as tegra has or generic via /sys/kernel/reboot/
gclement has joined #armlinux
<monstr>
b) overload nvm location
<monstr>
because nvmem-reboot-mode is just writing to it but at the end it is up to nvmem driver to define behavior on read part
<monstr>
it means on writing you could write reason for reboot and for reading you can get last reason
<monstr>
and user interface is done via nvmem which has user and kernel interfaces
<monstr>
issue with enum reboot_mode would be to defining other scopes. I am not closely working with our power management team but I know there are some other modes for reboot.
<linusw__>
ukleinek: the only time we actually need to check for if (gpiod) is when there are some group of statements including delays that can be avoided for an optional gpiod.
monstr has quit [Ping timeout: 252 seconds]
psydroid has joined #armlinux
monstr has joined #armlinux
manchaw has quit [Quit: Connection closed for inactivity]
tlwoerner has quit [Ping timeout: 256 seconds]
tlwoerner has joined #armlinux
cbeznea has quit [Quit: Leaving]
mvaittin has quit [Ping timeout: 240 seconds]
prabhakar has quit [Ping timeout: 260 seconds]
prabhakarlad has quit [Ping timeout: 250 seconds]
headless has joined #armlinux
headless has quit [Read error: Connection reset by peer]
headless_ has joined #armlinux
headless_ has quit [Ping timeout: 256 seconds]
headless_ has joined #armlinux
frieder has quit [Remote host closed the connection]
headless_ has quit [Quit: Konversation terminated!]
sally has quit [Read error: Connection reset by peer]
sally_ has joined #armlinux
sally has joined #armlinux
amitk_ has joined #armlinux
sally_ has quit [Ping timeout: 268 seconds]
sally has quit [Ping timeout: 256 seconds]
rgallaispou has quit [Quit: Leaving.]
gclement has quit [Ping timeout: 255 seconds]
sakman has quit [Remote host closed the connection]
apritzel has quit [Remote host closed the connection]