From: Michael Ellerman <michael@ellerman.id.au>
To: Nicolas DET <nd@bplan-gmbh.de>
Cc: akpm@osdl.org, linuxppc-dev@ozlabs.org,
Sven Luther <sl@bplan-gmbh.de>,
tilmann@bitterberg.de
Subject: Re: [PATCH] enable RTAS /proc for PowerPC/CHRP platform
Date: Wed, 18 Oct 2006 16:15:09 +1000 [thread overview]
Message-ID: <1161152109.7906.6.camel@localhost.localdomain> (raw)
In-Reply-To: <4535C0F8.1070905@bplan-gmbh.de>
[-- Attachment #1: Type: text/plain, Size: 2379 bytes --]
On Wed, 2006-10-18 at 07:51 +0200, Nicolas DET wrote:
> Christoph Hellwig wrote:
> >> --- a/arch/powerpc/kernel/rtas-proc.c 2006-10-14
> 05:34:03.000000000 +0200
> >> +++ b/arch/powerpc/kernel/rtas-proc.c 2006-10-16
> 10:46:16.000000000 +0200
> >> @@ -253,43 +253,70 @@ static void get_location_code(struct seq
> >> static void check_location_string(struct seq_file *m, char *c);
> >> static void check_location(struct seq_file *m, char *c);
> >>
> >> +#ifdef CONFIG_PPC64
> >> +#define PROCRTAS_ROOT "ppc64"
> >> +#else
> >> +#define PROCRTAS_ROOT "ppc"
> >
> > Please don't do any pathname changes. Even if ppc64 isn't correct it's
> > what applications expect and what we should provide for a coherent user
> > interface.
>
> Humm, ok.
> However, in this case 'ppc' (could be 32 or 64 as it is not specified)
> is more generic than 'ppc64'.
But it's called '/proc/ppc64' right now on lots of machines, so you
can't go changing it.
> > This should be the only change you need, and it should follow kernel
> > coding style, aka:
> >
> > if (!machine_is(pseries) && !machine_is(chrp))
> > return -ENODEV;
> >
> >> rtas_node = of_find_node_by_name(NULL, "rtas");
> >> if (rtas_node == NULL)
> >> return -ENODEV;
> >
> > And given this check I wonder why we need the platform check at all. It
> > should be safe to just remove it.
> >
> >
>
> Indeed, however I can only test on CHRP. I'll remove the check in the
> upcomming patch.
That should be fine AFAICT, you should probably just check that each of
the proc routines checks for errors - ie. just because you have an
"/rtas" node doesn't mean you necessarily have "/rtas/set-indicator" or
whatever.
> The patch also include a small code to create the /proc/ppc/rtas entry.
> Should this be done here, or somewhere in arch/powerpc/chrp/setup.c ?
That code is almost entirely the same as proc_ppc64_create(), so I think
you should try and merge them - we want to minimise the number of
foo_ppc64() and foo_ppc32() routines we have.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 191 bytes --]
next prev parent reply other threads:[~2006-10-18 6:15 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-10-17 11:29 [PATCH] enable RTAS /proc for PowerPC/CHRP platform Nicolas DET
2006-10-17 13:22 ` Christoph Hellwig
2006-10-17 22:22 ` Arnd Bergmann
2006-10-18 22:39 ` Benjamin Herrenschmidt
2006-10-20 8:13 ` Nicolas DET
2006-10-18 5:51 ` Nicolas DET
2006-10-18 6:05 ` Sven Luther
2006-10-18 6:15 ` Michael Ellerman [this message]
2006-10-18 6:34 ` Nicolas DET
2006-10-18 7:38 ` Olaf Hering
2006-10-18 22:38 ` Benjamin Herrenschmidt
2006-10-19 7:03 ` Olaf Hering
2006-10-19 23:35 ` Benjamin Herrenschmidt
2006-10-20 5:44 ` Olaf Hering
2006-10-20 5:56 ` Benjamin Herrenschmidt
2006-10-20 6:24 ` Sven Luther
2006-10-20 6:44 ` Olaf Hering
2006-10-20 6:58 ` Sven Luther
2006-10-20 7:12 ` Benjamin Herrenschmidt
2006-10-20 7:36 ` Sven Luther
2006-10-20 8:16 ` Benjamin Herrenschmidt
2006-10-20 7:20 ` Olaf Hering
2006-10-20 7:37 ` Sven Luther
2006-10-20 7:49 ` Olaf Hering
2006-10-20 8:12 ` Segher Boessenkool
2006-10-20 8:52 ` Sven Luther
2006-10-20 10:00 ` Olaf Hering
2006-10-20 13:59 ` Segher Boessenkool
2006-10-20 7:11 ` Benjamin Herrenschmidt
2006-10-20 7:14 ` Olaf Hering
2006-10-20 7:36 ` Benjamin Herrenschmidt
2006-10-20 10:01 ` Paul Mackerras
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=1161152109.7906.6.camel@localhost.localdomain \
--to=michael@ellerman.id.au \
--cc=akpm@osdl.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=nd@bplan-gmbh.de \
--cc=sl@bplan-gmbh.de \
--cc=tilmann@bitterberg.de \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.