From: Geert Uytterhoeven <geert@linux-m68k.org>
To: linux-sh@vger.kernel.org
Subject: Re: [PATCH 00/08] ARM: shmobile: Suspend on non-SMP update for r8a7790
Date: Fri, 06 Jun 2014 07:08:17 +0000 [thread overview]
Message-ID: <CAMuHMdWwx=Gf1hM20JSV3CrnL5KhQO_uL1SHfHa16pnyoQUK9Q@mail.gmail.com> (raw)
In-Reply-To: <20140605051505.18075.76727.sendpatchset@w520>
Hi Magnus,
On Fri, Jun 6, 2014 at 8:49 AM, Magnus Damm <magnus.damm@gmail.com> wrote:
> To try to improve the situation I'm considering adding a single setup
> function for mach-shmobile. I was playing around with a similar
> approach earlier but I could at that time not get any positive
> comments about setting up the smp_ops dynamically. In general I think
> it makes sense to setup a lot of similar callbacks from C instead of
> explicitly adding them to each and every SoC and board mach vector.
> Perhaps we could also deal with UP vs SMP at the same time?
>
> The idea with the code below would be to allow passing two pointers to
> the setup code:
> 1) function pointer for UP case
> 2) smp_ops pointer for SMP setup case
>
> The setup function (shmobile_init_cpus() below) would be responsible
> for the following:
> - if running as smp then register the smp_ops
> - if running as up then call the function pointer for setup
> - execute shmobile_init_delay()
> - install shmobile_init_late in the machine vector
>
> For the common case every machine vector we would only need dt_compat
> and init_early.
>
> What do you think?
Sounds reasonable.
However, I had a quick look at the code, and am no longer that positive
about it:
- .init_late() is too late to register the SMP ops, that's why there's a
.smp pointer, which is used much earlier (see setup_arch()),
- The machine vector is const, so you cannot install a handler later,
- In the end, you would basically replace the current machine vector
callback scheme (which is data) by setup functions (which are code),
which is moving away from what the machine vector was originally
intended for?
Anyway, if you want to go this way, it needs discussion on the ARM kernel
mailing list.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
next prev parent reply other threads:[~2014-06-06 7:08 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-05 5:15 [PATCH 00/08] ARM: shmobile: Suspend on non-SMP update for r8a7790 Magnus Damm
2014-06-05 8:01 ` Geert Uytterhoeven
2014-06-05 21:34 ` Magnus Damm
2014-06-06 6:49 ` Magnus Damm
2014-06-06 7:08 ` Geert Uytterhoeven [this message]
2014-06-06 7:36 ` Magnus Damm
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAMuHMdWwx=Gf1hM20JSV3CrnL5KhQO_uL1SHfHa16pnyoQUK9Q@mail.gmail.com' \
--to=geert@linux-m68k.org \
--cc=linux-sh@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).