From patchwork Sat Jan 3 03:59:15 2009 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Julian Calaby X-Patchwork-Id: 16363 X-Patchwork-Delegate: davem@davemloft.net Return-Path: X-Original-To: patchwork-incoming@ozlabs.org Delivered-To: patchwork-incoming@ozlabs.org Received: from vger.kernel.org (vger.kernel.org [209.132.176.167]) by ozlabs.org (Postfix) with ESMTP id B1716DDF77 for ; Sat, 3 Jan 2009 14:59:22 +1100 (EST) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751840AbZACD7S (ORCPT ); Fri, 2 Jan 2009 22:59:18 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1756694AbZACD7S (ORCPT ); Fri, 2 Jan 2009 22:59:18 -0500 Received: from rv-out-0506.google.com ([209.85.198.227]:11339 "EHLO rv-out-0506.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751840AbZACD7R (ORCPT ); Fri, 2 Jan 2009 22:59:17 -0500 Received: by rv-out-0506.google.com with SMTP id k40so6130007rvb.1 for ; Fri, 02 Jan 2009 19:59:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=lLKgBT0UCZGMmzzeQFrBS5zizF2CFIUU+15ksWReDmg=; b=cC3WTXo1O17w6JmMQznPlFCruPHk7yauGxodwxPsR8J6uoz5FpzK+dBfxBBiw+Fouy thVpiu7kmcLnTlnHhcpRfocxGIKUbEMD7YIf4IGhrD+MZo4kdd//apOcmm4UoqJBBzsM xXBZLa++vW7Gjh2FXM9mEWoaotO+9T67HO6cw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=hIRTu18lHKb6A7XI3bxmBl2tSszctDsGWKHP0ogvVqKGiKNeEH5mk9fk3SBlmfo5up /DUHSL8bp7c1CDk5GFu5DPSuq37L+NNzoBqnl9+wyH4U1aZnak9dAdm0T4JhTCx2mHhp q7GRX9sCkVioqJd2sRBIf/yDcmPjRvONj2plU= Received: by 10.141.164.13 with SMTP id r13mr9163641rvo.33.1230955155630; Fri, 02 Jan 2009 19:59:15 -0800 (PST) Received: by 10.141.176.5 with HTTP; Fri, 2 Jan 2009 19:59:15 -0800 (PST) Message-ID: <646765f40901021959jd666f10t16c233a7d5dbcf4@mail.gmail.com> Date: Sat, 3 Jan 2009 14:59:15 +1100 From: "Julian Calaby" To: "David Miller" Subject: Re: sparc - next unification bits? Cc: sam@ravnborg.org, sparclinux@vger.kernel.org In-Reply-To: <20090102.182229.07047691.davem@davemloft.net> MIME-Version: 1.0 Content-Disposition: inline References: <20081227211236.GA16704@uranus.ravnborg.org> <20090102.182229.07047691.davem@davemloft.net> Sender: sparclinux-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: sparclinux@vger.kernel.org On Sat, Jan 3, 2009 at 13:22, David Miller wrote: > From: Sam Ravnborg > Date: Sat, 27 Dec 2008 22:12:36 +0100 > >> So far I done some random unification where it was simple >> and I could do so more or less in a mechanical fashion. >> >> But I'm running out of the easy tasks. >> >> Are there any places/files where you would like to see >> some additional effort being made - but yet simple >> enough that I can do it? > > An area with a lot of potential is arch/sparc/prom, I think. > > The trick is to decide upon a backend interface for the > actual calls into the firmware. > > Sparc32 calls into the firmware by ->foo() method calls, > and the base of the structure with the function pointers > is given to the kernel at boot time. > > Sparc64 on the other hand calls into the firmware by > invoking a single function address, again given to the > kernel in a register at boot time, but the method to > invoke is indicated by a string and the args are pushed > on the stack (and the args are obtained from stack slots). > > Perhaps if a suitable abstraction for this stuff is > designed, this difference in calling conventions could be > handled which would make most of the arch/sparc/prom/ > code generic. > > For example we could have some prom_invoke() thing that > would take the method name string as one of it's args, > but that would be totally ignored by 32-bit sparc's > implementation of this interface. Likewise, there would > be a method name arg, which in turn would be not used > by 64-bit sparc. > > Something like that. Just throwing out some ideas. Adding my 2 cents: After having a look at the code involved - particularly the implementation of functions in arch/sparc{,64}/prom/tree.c - it seems that the prom_*() functions are superficially identical between sparc32 and sparc64 and the __prom_*() functions are completely different. This gives me a bit more of an insight as to how these two architectures are different and how the interfaces work. As such, it may be beneficial to standardize around an interface similar to sparc32's - i.e. a structure with ->foo() calls - and make an implementation of this that uses sparc64's single function pointer. I've attached a small patch that shows what I'm thinking of - however, as my C's a little rusty, it's utterly inane and won't compile in any sensible manner - given, of course, that Gmail hasn't mangled it. Of course, a real implementation would split all the sparc{32,64}ness out into separate files, leaving a nice set of pristine prom/*.c files that reference this structure, but that isn't something you can knock up in your lunch break. diff --git a/arch/sparc/prom/tree.c b/arch/sparc/prom/tree.c index f228fe0..59f8761 100644 --- a/arch/sparc/prom/tree.c +++ b/arch/sparc/prom/tree.c @@ -20,9 +20,23 @@ extern void restore_current(void); static char promlib_buf[128]; -/* Internal version of prom_getchild that does not alter return values. */ -int __prom_getchild(int node) -{ +struct prom_ops { + int *get_child(int node); +} + +#ifdef SPARC64 + +int get_child_s64(int node) { + return p1275_cmd ("child", P1275_INOUT(1, 1), node); +} + +struct prom_ops *prom_ops = { + .get_child = get_child_s64; +} + +#else + +int get_child_s32(int node) { unsigned long flags; int cnode; @@ -34,6 +48,12 @@ int __prom_getchild(int node) return cnode; } +struct prom_ops *prom_ops = { + .get_child = get_child_s32; +} + +#endif + /* Return the child of node 'node' or zero if no this node has no * direct descendent. */ @@ -44,8 +64,8 @@ int prom_getchild(int node) if (node == -1) return 0; - cnode = __prom_getchild(node); + cnode = prom_ops->get_child(node); if (cnode == 0 || cnode == -1) return 0; return cnode;