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

[Christian Ruppert <christian.ruppert-ux6zf3SgZrrQT0dZR+AlfA@public.gmane.org>]

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).

Greetings,
  Christian