Re: arc platform code updates (was Re: [PATCH 2/2] i2c: designware: Add support for AMD I2C controller)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 10/10/2014 02:13 AM, Christian Ruppert wrote:
On Tue, Oct 07, 2014 at 12:35:29PM +0000, Vineet Gupta wrote:
+CC Guenter Roeck
[...]
However, the kernel-doc comment for init_machine in
mach_desc.h is now slightly confusing (still mentioning device tree).

A platform of future can still call of_platform_populate() etc to reparse the
stuff for say it's platform devices !
So I would think it is still relevant !

OK.

With this patch there remains only a single detail we need to manage
through platform-specific code: the reset handler. Today we still
provide a patch for the machine_restart function in reset.c to our
customers so that rebooting from the command line works. Do you have any
plans/ideas to fix this one as well?

Patches are welcome ;-)

ATM, I dont have a specific use-case for my current platforms, so can't write the
code - you can propose a patch and then we can work out what's best in general for
all ARC platforms. BTW there's a series in flight on related topic from Guenter so
please take a look at that too for big picture !

http://www.spinics.net/linux/lists/kernel/msg1840650.html

Actually, before sending my previous mail I looked at the current
implementation of the halt hook and didn't like it (otherwise I would
have proposed something in the lines). So this one is definitely a step
forward! I'm wondering about two things concerning reset, however:

1. Is the PM module the right place for a reset handler? On the one hand
    reset is functionally very similar to power off but on the other hand
    reset is technically not a power management functionality. If the PM
    module is not the right place, which would be the right place
    instead?

2. What would be the desired behaviour/semantics for a reset handler
    chain equivalent to the power off handler chain. I see two
    possibilities here:
    a) Implementation exactly like power off. Every handler is expected
       to reset the entire system and never returns.
    b) A more "modular" implementation where different subsystems are
       being reset sequentially (e.g. first reset peripherals through
       GPIO in "high priority" handlers and finally reset the core in the
       terminal "low priority" handler).


Hi Christian,

The restart handler patch series will hopefully make it into 3.18.
It will not be in kernel/power/ but in kernel/reboot.c which seemed
to be more appropriate. The semantics is exactly the same as for the
poweroff handler. Actually, the poweroff handler code is derived
from the restart handler code. Implementation is like 2a).

The restart handler code is available here:

https://git.kernel.org/cgit/linux/kernel/git/groeck/linux-staging.git/log/?h=restart-handler

There is also a tag, restart-handler-for-v3.18, which you can use to merge
the series into your tree if needed.

Hope this helps,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-i2c" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html




[Index of Archives]     [Linux GPIO]     [Linux SPI]     [Linux Hardward Monitoring]     [LM Sensors]     [Linux USB Devel]     [Linux Media]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]

  Powered by Linux