From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Antonino A. Daplas" Subject: Re: Re: [PATCH] fbdev: Fix IO access in rivafb Date: Sun, 14 Nov 2004 05:29:46 +0800 Message-ID: <200411140529.48977.adaplas@hotpop.com> References: <200411080521.iA85LbG6025914@hera.kernel.org> <200411132000.31465.adaplas@hotpop.com> Reply-To: linux-fbdev-devel@lists.sourceforge.net Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: Received: from sc8-sf-mx1-b.sourceforge.net ([10.3.1.11] helo=sc8-sf-mx1.sourceforge.net) by sc8-sf-list1.sourceforge.net with esmtp (Exim 4.30) id 1CT5TE-0001mx-6a for linux-fbdev-devel@lists.sourceforge.net; Sat, 13 Nov 2004 13:30:08 -0800 Received: from smtp-out.hotpop.com ([38.113.3.61]) by sc8-sf-mx1.sourceforge.net with esmtp (Exim 4.41) id 1CT5TC-0000FT-6S for linux-fbdev-devel@lists.sourceforge.net; Sat, 13 Nov 2004 13:30:08 -0800 Received: from hotpop.com (kubrick.hotpop.com [38.113.3.103]) by smtp-out.hotpop.com (Postfix) with SMTP id AA5119E5213 for ; Sat, 13 Nov 2004 21:29:49 +0000 (UTC) In-Reply-To: Content-Disposition: inline Sender: linux-fbdev-devel-admin@lists.sourceforge.net Errors-To: linux-fbdev-devel-admin@lists.sourceforge.net List-Unsubscribe: , List-Id: List-Post: List-Help: List-Subscribe: , List-Archive: Content-Type: text/plain; charset="us-ascii" To: Linus Torvalds , adaplas@pol.net Cc: Linux Fbdev development list , Guido Guenther , Benjamin Herrenschmidt , Linux Kernel list , Andrew Morton On Sunday 14 November 2004 02:00, Linus Torvalds wrote: > On Sat, 13 Nov 2004, Antonino A. Daplas wrote: > > Why not use in_be* and out_be* for __raw_read and raw_write? > > Please don't start using some stupid magic ppc-specific macros for a > driver that has no reason to be PPC-specific. It then only causes bugs > that show on one platform and not another. I'm not. I'm just wondering that if the other approach was taken (keep the hardware in little endian mode), then the write/read* macros, which are just wrappers for in_le*/out_le*, would have been used. Would it help fix (or cover up) bugs that are in PPC but not x86? Tony ------------------------------------------------------- This SF.Net email is sponsored by: InterSystems CACHE FREE OODBMS DOWNLOAD - A multidimensional database that combines robust object and relational technologies, making it a perfect match for Java, C++,COM, XML, ODBC and JDBC. www.intersystems.com/match8 From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261172AbUKMVaL (ORCPT ); Sat, 13 Nov 2004 16:30:11 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261180AbUKMVaL (ORCPT ); Sat, 13 Nov 2004 16:30:11 -0500 Received: from smtp-out.hotpop.com ([38.113.3.51]:39375 "EHLO smtp-out.hotpop.com") by vger.kernel.org with ESMTP id S261172AbUKMVaF (ORCPT ); Sat, 13 Nov 2004 16:30:05 -0500 From: "Antonino A. Daplas" Reply-To: adaplas@pol.net To: linux-fbdev-devel@lists.sourceforge.net, Linus Torvalds , adaplas@pol.net Subject: Re: [Linux-fbdev-devel] Re: [PATCH] fbdev: Fix IO access in rivafb Date: Sun, 14 Nov 2004 05:29:46 +0800 User-Agent: KMail/1.5.4 Cc: Linux Fbdev development list , Guido Guenther , Benjamin Herrenschmidt , Linux Kernel list , Andrew Morton References: <200411080521.iA85LbG6025914@hera.kernel.org> <200411132000.31465.adaplas@hotpop.com> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200411140529.48977.adaplas@hotpop.com> X-HotPOP: ----------------------------------------------- Sent By HotPOP.com FREE Email Get your FREE POP email at www.HotPOP.com ----------------------------------------------- Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org On Sunday 14 November 2004 02:00, Linus Torvalds wrote: > On Sat, 13 Nov 2004, Antonino A. Daplas wrote: > > Why not use in_be* and out_be* for __raw_read and raw_write? > > Please don't start using some stupid magic ppc-specific macros for a > driver that has no reason to be PPC-specific. It then only causes bugs > that show on one platform and not another. I'm not. I'm just wondering that if the other approach was taken (keep the hardware in little endian mode), then the write/read* macros, which are just wrappers for in_le*/out_le*, would have been used. Would it help fix (or cover up) bugs that are in PPC but not x86? Tony