Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1286860 > unrolled thread

[RFC][PATCH] misc: Introduce reboot_reason driver

Back to article view | Back to linux.kernel

Contents

  [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-08 22:30 +0100
    Re: [RFC][PATCH] misc: Introduce reboot_reason driver Arnd Bergmann <arnd@arndb.de> - 2015-12-08 23:00 +0100
      Re: [RFC][PATCH] misc: Introduce reboot_reason driver Bjorn Andersson <bjorn.andersson@sonymobile.com> - 2015-12-08 23:20 +0100
        Re: [RFC][PATCH] misc: Introduce reboot_reason driver Rob Herring <robh+dt@kernel.org> - 2015-12-08 23:50 +0100
      Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-09 01:20 +0100
        Re: [RFC][PATCH] misc: Introduce reboot_reason driver Sascha Hauer <s.hauer@pengutronix.de> - 2015-12-09 10:00 +0100
          Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-09 22:50 +0100
    Re: [RFC][PATCH] misc: Introduce reboot_reason driver Bjorn Andersson <bjorn.andersson@sonymobile.com> - 2015-12-08 23:10 +0100
      Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-09 01:30 +0100
        Re: [RFC][PATCH] misc: Introduce reboot_reason driver Arnd Bergmann <arnd@arndb.de> - 2015-12-09 11:10 +0100
          Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-10 02:30 +0100
            Re: [RFC][PATCH] misc: Introduce reboot_reason driver Arnd Bergmann <arnd@arndb.de> - 2015-12-10 16:00 +0100
              Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-10 20:00 +0100
                Re: [RFC][PATCH] misc: Introduce reboot_reason driver Rob Herring <robh+dt@kernel.org> - 2015-12-10 21:30 +0100
                  Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-10 22:50 +0100
                    Re: [RFC][PATCH] misc: Introduce reboot_reason driver Arnd Bergmann <arnd@arndb.de> - 2015-12-10 23:20 +0100
      Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-10 02:40 +0100
        Re: [RFC][PATCH] misc: Introduce reboot_reason driver Arnd Bergmann <arnd@arndb.de> - 2015-12-10 10:10 +0100
          Re: [RFC][PATCH] misc: Introduce reboot_reason driver Tomas Winkler <tomasw@gmail.com> - 2015-12-10 10:30 +0100
            Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-10 20:10 +0100
              Re: [RFC][PATCH] misc: Introduce reboot_reason driver One Thousand Gnomes <gnomes@lxorguk.ukuu.org.uk> - 2015-12-10 21:00 +0100
                Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-10 21:10 +0100
    Re: [RFC][PATCH] misc: Introduce reboot_reason driver Rob Herring <robh+dt@kernel.org> - 2015-12-08 23:30 +0100
      Re: [RFC][PATCH] misc: Introduce reboot_reason driver John Stultz <john.stultz@linaro.org> - 2015-12-09 01:40 +0100
    Re: [RFC][PATCH] misc: Introduce reboot_reason driver Sascha Hauer <s.hauer@pengutronix.de> - 2015-12-09 10:00 +0100
    Re: [RFC][PATCH] misc: Introduce reboot_reason driver Sascha Hauer <s.hauer@pengutronix.de> - 2015-12-09 10:10 +0100

Page 2 of 2 — ← Prev page 1 [2]

#1288889

On Thu, 10 Dec 2015 11:04:03 -0800
John Stultz <john.stultz@linaro.org> wrote:

> On Thu, Dec 10, 2015 at 1:20 AM, Tomas Winkler <tomasw@gmail.com> wrote:
> > Intel uses EFI variables for that on  some AOS platforms. There is a
> > need for persistent storage abstraction and generalize the reboot
> > reasons strings.
> 
> Yea. I've been told there isn't any sort of standardized method for
> EFI here. But I have seen a few different implementations floating
> around.
> 
> One of the machines I want to support with this driver is actually
> using a UEFI bootloader, but we don't have separate storage to use to
> communicate back via the UEFI methods, so the ram based approach looks
> like the best solution.
> 
> > Second, I wonder why this is submitted under drivers/misc when it
> > doesn't bind the misc API.
> 
> Heh. Apologies. Its more of a "where do I put this?", misc rather then
> "this should be part of the established misc infrastructure!"
> Suggestions for alternative locations?

Other than providing a reason (which could be via sysfs) I don't actually
see what in the rest of it doesn't either live in the platform arch/ code
or for standardised firmware in the EFI / ACPI or some other drivers.

sysfs node provides the reason string, reboot notifiers get run before
reboot, and it's up to the platform to decide if it wants to do anything
with the reason string before it hits the switch.

I don't see the need for anything but an extra /sys/power node in the core
kernel ? The rest from a core kernel perspective is already there.

Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1288890

On Thu, Dec 10, 2015 at 11:57 AM, One Thousand Gnomes
<gnomes@lxorguk.ukuu.org.uk> wrote:
> On Thu, 10 Dec 2015 11:04:03 -0800
> John Stultz <john.stultz@linaro.org> wrote:
>> On Thu, Dec 10, 2015 at 1:20 AM, Tomas Winkler <tomasw@gmail.com> wrote:
>> > Second, I wonder why this is submitted under drivers/misc when it
>> > doesn't bind the misc API.
>>
>> Heh. Apologies. Its more of a "where do I put this?", misc rather then
>> "this should be part of the established misc infrastructure!"
>> Suggestions for alternative locations?
>
> Other than providing a reason (which could be via sysfs) I don't actually
> see what in the rest of it doesn't either live in the platform arch/ code
> or for standardised firmware in the EFI / ACPI or some other drivers.

Ok. Will move to drivers/firmware unless suggested otherwise.

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286902

On Tue, Dec 8, 2015 at 3:29 PM, John Stultz <john.stultz@linaro.org> wrote:
> This patch adds a basic driver to allow for commands like
> "reboot bootloader" and "reboot recovery" to communicate this
> reboot-reason to the bootloader.
>
> This is commonly done on Android devices, in order to reboot
> the device into fastboot or recovery mode. It also supports
> custom OEM specific commands, via "reboot oem-<value>".

What are some examples of OEM specific commands?

> This driver pulls the phys memory address from DT as well as
> the magic reason values that are written to the address for
> each mode.

Starting with what does the h/w look like, this is typically
implemented with some sort of persistent register(s) either in the SOC
or PMIC. So I think persistent memory/registers is what we need to
describe in DT. Perhaps this could be tied into pstore (an overkill
for a single register, but useful if you already have pstore support
for persistent memory)? The 2nd part is which register to use and the
mapping of values to reboot reason. Do these vary within SOC families?
If not, then we should just hardcode them in the reboot drivers which
are already vendor specific.

Also, while trying to standardize the values for reboot reason
probably won't work short term, we should define something so people
will start using it. We also should consider any implications with
PSCI.

Rob
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1286936

On Tue, Dec 8, 2015 at 2:26 PM, Rob Herring <robh+dt@kernel.org> wrote:
> On Tue, Dec 8, 2015 at 3:29 PM, John Stultz <john.stultz@linaro.org> wrote:
>> This patch adds a basic driver to allow for commands like
>> "reboot bootloader" and "reboot recovery" to communicate this
>> reboot-reason to the bootloader.
>>
>> This is commonly done on Android devices, in order to reboot
>> the device into fastboot or recovery mode. It also supports
>> custom OEM specific commands, via "reboot oem-<value>".
>
> What are some examples of OEM specific commands?

Actually, I don't know. That bit was preserved from the 3.4 based
logic in a vendor tree.

I can drop it for now if you'd rather.


>> This driver pulls the phys memory address from DT as well as
>> the magic reason values that are written to the address for
>> each mode.
>
> Starting with what does the h/w look like, this is typically
> implemented with some sort of persistent register(s) either in the SOC
> or PMIC. So I think persistent memory/registers is what we need to
> describe in DT. Perhaps this could be tied into pstore (an overkill
> for a single register, but useful if you already have pstore support
> for persistent memory)?

Hrm. Yea. I'm hesitant to tie it into pstore, but that's partly due to
not wanting the bootloader to have to parse the pstore area (ideally
the bootloader doesn't touch it).

To me having the bootloader reserve a page of memory and having the
kernel map and write that reserved page makes the most sense to me.
It then being special memory mapped registers or just a reserved page
can be somewhat equivalent.

But maybe I'm being naive?

> The 2nd part is which register to use and the
> mapping of values to reboot reason. Do these vary within SOC families?
> If not, then we should just hardcode them in the reboot drivers which
> are already vendor specific.

I'm not aware of differences between SOC families for the values,
though the addresses might change.

> Also, while trying to standardize the values for reboot reason
> probably won't work short term, we should define something so people
> will start using it.

Ack. Though if the values are mostly custom/magic, is having them
defined in the DT problematic? Or do you just want  macros for
something like something like
   reason,bootloader = <GENERIC_REASON_BOOTLOADER>; ?

> We also should consider any implications with
> PSCI.

Sorry. I'm ignorant here. What would those implications possibly be?

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287203

Hi John,

Only a small comment

On Tue, Dec 08, 2015 at 01:29:22PM -0800, John Stultz wrote:
> +static int reboot_reason_probe(struct platform_device *pdev)
> +{
> +	struct resource *res;
> +	u32 val;
> +	int i;
> +
> +	/* initialize the reasons */
> +	for (i = 0; i < MAX_REASONS; i++)
> +		reasons[i] = -1;
> +
> +	/* Try to grab the reason io address */
> +	res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> +	reboot_reason_addr = devm_ioremap_resource(&pdev->dev, res);
> +	if (IS_ERR(reboot_reason_addr))
> +		return PTR_ERR(reboot_reason_addr);
> +
> +	/* initialize specified reasons from DT */
> +	if (!of_property_read_u32(pdev->dev.of_node, "reason,none", &val))
> +		reasons[NONE] = val;

can be simplified to:

	of_property_read_u32(pdev->dev.of_node, "reason,none", &reasons[NONE]);

No need to check first, &reasons[NONE] will only be modified when the
property exists.

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1287209

Hi John,

On Tue, Dec 08, 2015 at 01:29:22PM -0800, John Stultz wrote:
> This patch adds a basic driver to allow for commands like
> "reboot bootloader" and "reboot recovery" to communicate this
> reboot-reason to the bootloader.
> 
> This is commonly done on Android devices, in order to reboot
> the device into fastboot or recovery mode. It also supports
> custom OEM specific commands, via "reboot oem-<value>".
> 
> This driver pulls the phys memory address from DT as well as
> the magic reason values that are written to the address for
> each mode.
> 
> For an example, this patch also adds the DT support for
> the nexus7 device via its dts (which is not yet upstream).
> 
> Thoughts and feedback would be appreciated!

I wonder if 'reason' is the correct word. This driver says nothing about
the reason why we reboot, but more what we should do next. Maybe
something like purpose, scope or intention is more appropriate?

Sascha

-- 
Pengutronix e.K.                           |                             |
Industrial Linux Solutions                 | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0    |
Amtsgericht Hildesheim, HRA 2686           | Fax:   +49-5121-206917-5555 |
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Page 2 of 2 — ← Prev page 1 [2]

Back to top | Article view | linux.kernel

csiph-web