From vagabon.xyz@gmail.com Thu Feb 1 09:52:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 09:52:23 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.236]:29885 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038877AbXBAJwT (ORCPT ); Thu, 1 Feb 2007 09:52:19 +0000 Received: by qb-out-0506.google.com with SMTP id p30so36241qba for ; Thu, 01 Feb 2007 01:51:16 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=h3LWFQG8Ncz1zcOEL0Yvmn4wTKU8W8s+6RDsUNm2egeAHeI9pOa8T9XELOJZacDZx6s9EkCl3HiU9mo8Tv7lmdx2rPWUoZRgjnOeb3x4MR67wt1HnAxic34bO/WQcNHC/awkc8Xa7V/lkbVpig1aSU1ivWdPRl6OMv5/0CY/mhQ= Received: by 10.114.181.1 with SMTP id d1mr133641waf.1170323475737; Thu, 01 Feb 2007 01:51:15 -0800 (PST) Received: by 10.114.134.16 with HTTP; Thu, 1 Feb 2007 01:51:15 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2007 10:51:15 +0100 From: "Franck Bui-Huu" To: "Maciej W. Rozycki" Subject: Re: RFC: Sentosa boot fix Cc: "Atsushi Nemoto" , dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070129161450.GA3384@nevyn.them.org> <20070130.234537.126574565.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13871 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 1/30/07, Maciej W. Rozycki wrote: > On Tue, 30 Jan 2007, Atsushi Nemoto wrote: > > > Though I do not object to remove "&& !defined(CONFIG_BUILD_ELF64)" > > from __pa_page_offset(), are there any point of CONFIG_BUILD_ELF64=y > > if your load address was CKSEG0? > > Checking for code correctness and validation of the toolchain (Linux is > one of the few non-PIC users of (n)64) without having to chase hardware > that would support running from XPHYS without serious pain (the firmware > being the usual offender). > This use case was unknown by the time we introduced __pa_page_offset(). Basically this macro assumes that if BUILD_ELF64 is set the load address is in XKPHYS. This allows to simplify __pa_page_offset() definition for this case. However if BUILD_ELF64 is not set then the macro deals with both CKSEG0 and XKPHYS virtual addresses. > That said, I have not checked the every single use of __pa_page_offset(), > but the sole existence of this condition raises a question about whether > we are sure __pa_page_offset() is going to be only used on virtual > addresses in the same segment the kernel is linked to. Well it all depends if we consider the case with BUILD_ELF64 set and a load address in CKSEG0 a useful case. If so, then we can remove "&& !defined(CONFIG_BUILD_ELF64)" from __pa_page_offset(). It shouldn't hurt the case where BUILD_ELF64 is not set and Atsushi seems to agree. BTW, maybe we can simply remove BUILD_ELF64 at all, since it's only used to add '-msym32' switch in the makefile. This switch could be automatically be added by the makefile instead thanks the following condition: if CONFIG_64BITS and ${load-y} in CKSEG0 cflags-y += -msym32 endif what do you think ? > Sometimes > references to both CKSEG0 and XPHYS may be used in the same kernel, e.g. > because the the kernel is linked to XPHYS, but the firmware is limited to > accept CKSEG0 addresses only (and we do call back into firmware on some > platforms). > Please keep these conversions in the platform specific codes before calling back the firmware. -- Franck From giometti@enneenne.com Thu Feb 1 10:02:13 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 10:02:17 +0000 (GMT) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:27863 "EHLO mail.enneenne.com") by ftp.linux-mips.org with ESMTP id S20038889AbXBAKCN (ORCPT ); Thu, 1 Feb 2007 10:02:13 +0000 Received: from zaigor.enneenne.com ([192.168.32.1]) by mail.enneenne.com with esmtp (Exim 4.50) id 1HCYi6-000491-Pt; Thu, 01 Feb 2007 10:58:34 +0100 Received: from giometti by zaigor.enneenne.com with local (Exim 4.63) (envelope-from ) id 1HCYie-0001ri-Gd; Thu, 01 Feb 2007 10:59:04 +0100 Date: Thu, 1 Feb 2007 10:59:04 +0100 From: Rodolfo Giometti To: Paul Mundt , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-mips@linux-mips.org Message-ID: <20070201095904.GE8882@enneenne.com> References: <20070129230755.GA8705@enneenne.com> <20070130010055.GA15907@linux-sh.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070130010055.GA15907@linux-sh.org> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Connect-IP: 192.168.32.1 X-SA-Exim-Mail-From: giometti@enneenne.com Subject: Advice on battery support [was: Advice on APM-EMU reunion] X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on mail.enneenne.com) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13872 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@enneenne.com Precedence: bulk X-list: linux-mips On Tue, Jan 30, 2007 at 10:00:55AM +0900, Paul Mundt wrote: > However, it has since been reposted: > > http://article.gmane.org/gmane.linux.kernel/485833 > http://article.gmane.org/gmane.linux.kernel/485834 > http://article.gmane.org/gmane.linux.kernel/485835 > http://article.gmane.org/gmane.linux.kernel/485837 > > and merged back in to -mm. This is all post 2.6.20 stuff, though.. Ok, starting from these patches I'd like to add a "battery support" to the kernel. What I suppose to do is a new class with a proper methods useful to collect several info on battery status, such as get_ac_line_status() get_battery_status(), get_battery_flags(), get_remaining_battery_life() and so on. The output will be APM-like into file "/proc/apm" (one line per battery, or just the "main"/first one?) so that existing applications continue to work and under sysfs into "/sysfs/class/battery". Is it sane? :) Thanks in advance, Rodolfo -- GNU/Linux Solutions e-mail: giometti@enneenne.com Linux Device Driver giometti@gnudd.com Embedded Systems giometti@linux.it UNIX programming phone: +39 349 2432127 From anemo@mba.ocn.ne.jp Thu Feb 1 10:07:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 10:07:48 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:4406 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20038891AbXBAKHo (ORCPT ); Thu, 1 Feb 2007 10:07:44 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 1 Feb 2007 19:07:43 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 1AAB741D4E; Thu, 1 Feb 2007 19:07:19 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 0711A410FD; Thu, 1 Feb 2007 19:07:19 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l11A7IW0036167; Thu, 1 Feb 2007 19:07:18 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 01 Feb 2007 19:07:17 +0900 (JST) Message-Id: <20070201.190717.55145997.nemoto@toshiba-tops.co.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, sam@catalyst.net.nz Subject: Re: Kernel issues on R4000/R4000 SC and MC From: Atsushi Nemoto In-Reply-To: <20070131130926.GA29562@linux-mips.org> References: <20070131130926.GA29562@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13873 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 31 Jan 2007 13:09:26 +0000, Ralf Baechle wrote: > Anyway, the issue boiled up again last week and was supposedly fixed for > linux-2.6.17-rc7 which I've just merged. I'd like to ask somebody with > one of the affected CPUs to test this. Below Nick Piggin's test program. What is the expected output of the test program? --- Atsushi Nemoto From vagabon.xyz@gmail.com Thu Feb 1 10:44:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 10:44:19 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.228]:54086 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038907AbXBAKoP (ORCPT ); Thu, 1 Feb 2007 10:44:15 +0000 Received: by qb-out-0506.google.com with SMTP id e12so37012qba for ; Thu, 01 Feb 2007 02:43:14 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=mgMbkbW3tIkDd1pfS2VXZ4aESMc4LKCOK0jJlDMwwIh/S8fNUniFw71makLPBbGb8h81EdbrVT7DSbPJXeW+IeiFbfJMI8xfGMVkBshH24lkgrFVH9V4Wprtc95wWo2sHvF6S997geQBM28Q2gTyFrgioxRBYlS07P2tVwnqMU4= Received: by 10.114.13.1 with SMTP id 1mr137544wam.1170326593259; Thu, 01 Feb 2007 02:43:13 -0800 (PST) Received: by 10.114.134.16 with HTTP; Thu, 1 Feb 2007 02:43:13 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2007 11:43:13 +0100 From: "Franck Bui-Huu" To: linux-mips Subject: Question about signal syscalls ! MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13874 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi, I'm probably missing something very obvious so the subject could have been "Dumb question of the week". So please be nice when answering ;) I'm wondering why we need to save/restore the static registers (s0...s7) when dealing with some signal system calls. Specially all of them which are declared by using save_static_function() macros. Thanks -- Franck From tsbogend@alpha.franken.de Thu Feb 1 10:54:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 10:54:12 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:18102 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20038876AbXBAKyF (ORCPT ); Thu, 1 Feb 2007 10:54:05 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1HCZWn-00028p-00; Thu, 01 Feb 2007 11:50:53 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id C40A6C2E08; Thu, 1 Feb 2007 11:36:18 +0100 (CET) Date: Thu, 1 Feb 2007 11:36:18 +0100 To: Atsushi Nemoto Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, sam@catalyst.net.nz Subject: Re: Kernel issues on R4000/R4000 SC and MC Message-ID: <20070201103618.GA25843@alpha.franken.de> References: <20070131130926.GA29562@linux-mips.org> <20070201.190717.55145997.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070201.190717.55145997.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.5.9i From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13875 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips On Thu, Feb 01, 2007 at 07:07:17PM +0900, Atsushi Nemoto wrote: > On Wed, 31 Jan 2007 13:09:26 +0000, Ralf Baechle wrote: > > Anyway, the issue boiled up again last week and was supposedly fixed for > > linux-2.6.17-rc7 which I've just merged. I'd like to ask somebody with > > one of the affected CPUs to test this. Below Nick Piggin's test program. > > What is the expected output of the test program? I can confirm, that it kills R4400SC/MC machines. I saw some "detected softlock" messages. With just one zero page (CPU without VCE) everything is fine Thomas. -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From sergio@amilda.org Thu Feb 1 13:09:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 13:09:58 +0000 (GMT) Received: from www.pc-net.at ([193.238.157.29]:53439 "EHLO MrWeb01.pc-net.at") by ftp.linux-mips.org with ESMTP id S20038930AbXBANJy (ORCPT ); Thu, 1 Feb 2007 13:09:54 +0000 Received: from localhost (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 0BD5D215ED1 for ; Thu, 1 Feb 2007 14:09:18 +0100 (CET) Received: from MrWeb01.pc-net.at ([127.0.0.1]) by localhost (MrWeb01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05032-07 for ; Thu, 1 Feb 2007 14:09:07 +0100 (CET) Received: from www.amilda.org (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 19316215EC9 for ; Thu, 1 Feb 2007 14:08:54 +0100 (CET) Received: from 201.240.249.124 (SquirrelMail authenticated user amilda0001) by www.amilda.org with HTTP; Thu, 1 Feb 2007 08:09:07 -0500 (PET) Message-ID: <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> In-Reply-To: <45C11812.9050808@wp.pl> References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> Date: Thu, 1 Feb 2007 08:09:07 -0500 (PET) Subject: Re: Advice needed. From: "Sergio Aguayo" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.6-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pc-net.at Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13876 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sergio@amilda.org Precedence: bulk X-list: linux-mips > > >>The board he is talking about is based on a rtl8186 which has few things >> in >>common with admtek 5120? >> >> > As i realize, it is a MIPS too, and he's talking about utilities, not > the kernel. (I'll download sources tomorrow, i have only GPRS internet > connection, so i will take several hours, and the i'll examine it). At > least some idea ;) > The realtek chipset by itself doesn't have many things in common with the ADM5120. But the board used (in this case by Edimax), is very similar for both chipsets. Almost the only thing needed to make the software of the one work in the other is placing some platform-dependent code in the kernel. The user-space should be quite the same (except the wireless driver, which is different). > > >>I think you had better using dd rather than cat, because /dev/mtdblock >> are >>block devices, and should be treated like that. If your image has a valid >>format, i.e : the bootloader accepts it, unless you made important >>modifications to the system code, it should at least be booting. >> >> > > Using dd also suggests padding resulting file to 2048*1024 bytes, am i > right? And using block size of 64k? > As of image, i remarked, that file resulting from reading /dev/mtd look > like: boot&variables(64k) + original image I have uploaded using Edimax > program(approx 1.9M) + zeros to the end of 2M boundary. > The structure (of the flash memory) is something like this: 32KB Boot loader 32KB Config stuff rest Kernel+BZIP2 RAMDISK The exact size of the kernel and the ramdisk varies greatly between firmware versions. YOu can find the start of the ramdisk by searching for the bzip2 signature (in this case 'BZh'). The kernel+ramdisk doesn't have to occupy the rest of the flash memory: the part not occupied by it is just undefined and its contents may be whatever. > So you think it may work? (dd ?) Image generation and upload using > Edimax-supplied tools works. > dd would certainly work. I would suggest you to check the way AMiLDA generates the firmware image. It's a lot more practical than a dd :D Regards, Sergio > W.P. > > > From macro@linux-mips.org Thu Feb 1 13:20:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 13:21:01 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:11791 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038926AbXBANU4 (ORCPT ); Thu, 1 Feb 2007 13:20:56 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 4575CE1CB9; Thu, 1 Feb 2007 14:20:13 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id rdqI+-4Y3Ser; Thu, 1 Feb 2007 14:20:12 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C61C5E1C92; Thu, 1 Feb 2007 14:20:12 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l11DKIYq001453; Thu, 1 Feb 2007 14:20:19 +0100 Date: Thu, 1 Feb 2007 13:20:15 +0000 (GMT) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Atsushi Nemoto , dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: RFC: Sentosa boot fix In-Reply-To: Message-ID: References: <20070129161450.GA3384@nevyn.them.org> <20070130.234537.126574565.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2510/Thu Feb 1 10:12:06 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13877 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 1 Feb 2007, Franck Bui-Huu wrote: > > Checking for code correctness and validation of the toolchain (Linux is > > one of the few non-PIC users of (n)64) without having to chase hardware > > that would support running from XPHYS without serious pain (the firmware > > being the usual offender). > > This use case was unknown by the time we introduced __pa_page_offset(). Well, I am afraid it was known well before. I introduced it first to 2.4 a while ago and I forward-ported the patch immediately to 2.6. Both changes went in on Oct 20th, 2004. The help text for the option has not changed since. And even 2.6.18 that I'm still using does not have this __pa_page_offset() macro! I did build various kernel versions with BUILD_ELF64 set for the DECstation (which links at 0xffffffff80040000). > Basically this macro assumes that if BUILD_ELF64 is set the load > address is in XKPHYS. This allows to simplify __pa_page_offset() > definition for this case. Wrong assumption. And nowhere guaranteed either. > However if BUILD_ELF64 is not set then the macro deals with both > CKSEG0 and XKPHYS virtual addresses. Indeed. > > That said, I have not checked the every single use of __pa_page_offset(), > > but the sole existence of this condition raises a question about whether > > we are sure __pa_page_offset() is going to be only used on virtual > > addresses in the same segment the kernel is linked to. > > Well it all depends if we consider the case with BUILD_ELF64 set and a > load address in CKSEG0 a useful case. If so, then we can remove "&& > !defined(CONFIG_BUILD_ELF64)" > from __pa_page_offset(). It shouldn't hurt the case where BUILD_ELF64 > is not set and Atsushi seems to agree. It hurts performance a little bit, so if you can assure the macro shall never be used on addresses from CKSEG0 if the load address is in XPHYS, then you can easily arrange for the load address to be passed to the preprocessor and use it as a condition here instead, which will be optimised away as required by the compiler. > BTW, maybe we can simply remove BUILD_ELF64 at all, since it's only > used to add '-msym32' switch in the makefile. This switch could be > automatically be added by the makefile instead thanks the following > condition: > > if CONFIG_64BITS and ${load-y} in CKSEG0 > cflags-y += -msym32 > endif > > what do you think ? I do not see enough of justification for -msym32 to be forced. This will also raise the minimum version of binutils required to 2.16 for the affected platforms, which may be a little bit too aggressive. > Please keep these conversions in the platform specific codes before > calling back the firmware. The DECstation uses CPHYSADDR() for these purposes; see e.g. arch/mips/dec/tc.c (not yet in the linux-mips.org repository -- to be merged from the -mm tree sometime after 2.6.20). But I recall seeing suggestions for this macro to be removed. Which I object against if there is no usable alternative available (and I refuse to implement generic functionality in platform-specific code -- there has been too much pain already to merge many such bits scattered around). Maciej From ralf@linux-mips.org Thu Feb 1 13:57:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 13:57:38 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:52379 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038963AbXBAN5g (ORCPT ); Thu, 1 Feb 2007 13:57:36 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l11DvZfO012933; Thu, 1 Feb 2007 13:57:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l11DvYYi012932; Thu, 1 Feb 2007 13:57:34 GMT Date: Thu, 1 Feb 2007 13:57:34 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips Subject: Re: Question about signal syscalls ! Message-ID: <20070201135734.GB12728@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13878 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 01, 2007 at 11:43:13AM +0100, Franck Bui-Huu wrote: > I'm probably missing something very obvious so the subject could have > been "Dumb question of the week". So please be nice when answering ;) > > I'm wondering why we need to save/restore the static registers > (s0...s7) when dealing with some signal system calls. Specially all > of them which are declared by using save_static_function() macros. The values of those registers need to be preserved so they can later be copied into the signal frame. Ralf From anemo@mba.ocn.ne.jp Thu Feb 1 14:32:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 14:32:48 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:62462 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038959AbXBAOcm (ORCPT ); Thu, 1 Feb 2007 14:32:42 +0000 Received: from localhost (p5011-ipad301funabasi.chiba.ocn.ne.jp [122.17.255.11]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 1FDDBB620; Thu, 1 Feb 2007 23:31:21 +0900 (JST) Date: Thu, 01 Feb 2007 23:31:20 +0900 (JST) Message-Id: <20070201.233120.126142024.anemo@mba.ocn.ne.jp> To: macro@linux-mips.org Cc: vagabon.xyz@gmail.com, dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: RFC: Sentosa boot fix From: Atsushi Nemoto In-Reply-To: References: X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13879 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 1 Feb 2007 13:20:15 +0000 (GMT), "Maciej W. Rozycki" wrote: > > if CONFIG_64BITS and ${load-y} in CKSEG0 > > cflags-y += -msym32 > > endif > > > > what do you think ? > > I do not see enough of justification for -msym32 to be forced. This will > also raise the minimum version of binutils required to 2.16 for the > affected platforms, which may be a little bit too aggressive. Well, $(call cc-option,-msym32) can be used safely. AFAIK -msym32 was added to gcc 4.0 which was released on Apr 2005, and binutils 2.16 was release on May 2005. So if gcc accepted -msym32 we can assume binutils accept too. I think killing BUILD_ELF64 and adding -msym32 automatically are good idea. Also I do not think __pa_page_offset() is critical for performance. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Feb 1 14:37:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 14:37:43 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:23524 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28573709AbXBAOhh (ORCPT ); Thu, 1 Feb 2007 14:37:37 +0000 Received: from localhost (p5011-ipad301funabasi.chiba.ocn.ne.jp [122.17.255.11]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id D77B7B8A3; Thu, 1 Feb 2007 23:36:15 +0900 (JST) Date: Thu, 01 Feb 2007 23:36:12 +0900 (JST) Message-Id: <20070201.233612.104641547.anemo@mba.ocn.ne.jp> To: macro@linux-mips.org Cc: vagabon.xyz@gmail.com, dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: RFC: Sentosa boot fix From: Atsushi Nemoto In-Reply-To: <20070201.233120.126142024.anemo@mba.ocn.ne.jp> References: <20070201.233120.126142024.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13880 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 01 Feb 2007 23:31:20 +0900 (JST), Atsushi Nemoto wrote: > Well, $(call cc-option,-msym32) can be used safely. AFAIK -msym32 was > added to gcc 4.0 which was released on Apr 2005, and binutils 2.16 was > release on May 2005. So if gcc accepted -msym32 we can assume > binutils accept too. Oops, Apr 2005 was before May 2005 :) Anyway I suppose gcc 4.x users are using modern binutils. --- Atsushi Nemoto From laurentp@wp.pl Thu Feb 1 14:48:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 14:48:51 +0000 (GMT) Received: from mx1.wp.pl ([212.77.101.5]:23989 "EHLO mx1.wp.pl") by ftp.linux-mips.org with ESMTP id S20038953AbXBAOsq (ORCPT ); Thu, 1 Feb 2007 14:48:46 +0000 Received: (wp-smtpd smtp.wp.pl 20587 invoked from network); 1 Feb 2007 15:47:42 +0100 Received: from apn-239-74.gprsbal.plusgsm.pl (HELO [87.251.239.74]) (laurentp@[87.251.239.74]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 1 Feb 2007 15:47:42 +0100 Message-ID: <45C1FE3D.8080304@wp.pl> Date: Thu, 01 Feb 2007 15:50:37 +0100 From: "W.P." User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: pl, en, en-us MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Advice needed. References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> In-Reply-To: <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13881 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: laurentp@wp.pl Precedence: bulk X-list: linux-mips >dd would certainly work. I would suggest you to check the way AMiLDA >generates the firmware image. It's a lot more practical than a dd :D > > Thanks, i'll look at this (just finished downloading source). But my question was NOT concerning GENERATING image (that part of toolchain works, so let it be), but FLasing it. Normally done by webs app. And as i see in Amilda, it uses the same scheme -> webs-buried C function. And I would have an alternative, because of: first -> have no source for webs-buried functions supplied by Edimax, so I have only choice of using built binary no chance to simply add some functionality, second -> webs is quite heavyweight, approx 450kb -> it is a lot on system with 2M Flash expanded to 5M Ramdisk. BTW maybe someone reading this knows what Edimax devices have 4M flash? W.P. From vagabon.xyz@gmail.com Thu Feb 1 14:55:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 14:55:47 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.235]:24938 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038949AbXBAOzm (ORCPT ); Thu, 1 Feb 2007 14:55:42 +0000 Received: by qb-out-0506.google.com with SMTP id e12so52977qba for ; Thu, 01 Feb 2007 06:54:41 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=SkXTeqZBbeJGcCiYhNhC/PoV6re7nKjS4LjRWGbS8liZ97x8boKrro7CSL1oUP2U5rthwbD/dw3dzU7qRBXTmL7DywdgymaCH81PpNev1EWU1q4aK5WhJC3aUkOM72AqdOilvje0KePFhXlRfTAoWixIpl07MLF68BnzGa1IewA= Received: by 10.114.75.1 with SMTP id x1mr151496waa.1170341680550; Thu, 01 Feb 2007 06:54:40 -0800 (PST) Received: by 10.114.134.16 with HTTP; Thu, 1 Feb 2007 06:54:40 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2007 15:54:40 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: Question about signal syscalls ! Cc: linux-mips In-Reply-To: <20070201135734.GB12728@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13882 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi Ralf, On 2/1/07, Ralf Baechle wrote: > The values of those registers need to be preserved so they can later be > copied into the signal frame. > Let's take for example sys_sigreturn(). In my understanding this syscall is used automatically when the signal handler returns. At this time, I don't see the point to save the static registers since they have been already saved by setup_sigcontext(). Actually I don't see why they need to be saved/restored at all... Let's say that process P1 sends a signal X to process P2 which has a handler defined for signal X and assume that the static registers are not saved at all. Signal X is received by P2. The signal handler is now executed in user mode. At this point what are the values of the static registers ? I would say they have the same values (let's call this state S) when P2 got interrupted. Once the signal handler returns into the kernel mode by executing 'syscall __NR_sigreturn' instructions, static registers still have state S and this state is normally preserved during sys_sigreturn syscall execution. So when resuming the normal execution of P2, the static registers have the correct values. What am I missing ? Thanks -- Franck From vagabon.xyz@gmail.com Thu Feb 1 16:00:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 16:00:55 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.229]:20638 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038951AbXBAQAv (ORCPT ); Thu, 1 Feb 2007 16:00:51 +0000 Received: by qb-out-0506.google.com with SMTP id e12so57305qba for ; Thu, 01 Feb 2007 07:59:50 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=CLdcfHwFCg+x8WpPOBm/F7ptKjybQFQ68I+WJBxTiRpNwCDrjb8Dx2heVe1ibXhrI0y7uacHL313AYLthdefEjRxiOtvhuHIQw4+5fyfotBXfDT3sdFoY0yQpYO6FQW4Mx2WK19yI9W3shb7MWBdaT3ze+Hg9iT6cI3cheknRlE= Received: by 10.114.75.1 with SMTP id x1mr173064waa.1170345589383; Thu, 01 Feb 2007 07:59:49 -0800 (PST) Received: by 10.114.134.16 with HTTP; Thu, 1 Feb 2007 07:59:49 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2007 16:59:49 +0100 From: "Franck Bui-Huu" To: "Maciej W. Rozycki" Subject: Re: RFC: Sentosa boot fix Cc: "Atsushi Nemoto" , dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070129161450.GA3384@nevyn.them.org> <20070130.234537.126574565.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13883 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Maciej W. Rozycki wrote: > On Thu, 1 Feb 2007, Franck Bui-Huu wrote: > >>> Checking for code correctness and validation of the toolchain (Linux is >>> one of the few non-PIC users of (n)64) without having to chase hardware >>> that would support running from XPHYS without serious pain (the firmware >>> being the usual offender). >> This use case was unknown by the time we introduced __pa_page_offset(). > > Well, I am afraid it was known well before. I introduced it first to 2.4 sorry I meant it wasn't for _me_. > > It hurts performance a little bit, so if you can assure the macro shall Well __pa() is only used in a few places. Futhermore it's used only during boot mem init so it really shouldn't hurt. > >> BTW, maybe we can simply remove BUILD_ELF64 at all, since it's only >> used to add '-msym32' switch in the makefile. This switch could be >> automatically be added by the makefile instead thanks the following >> condition: >> >> if CONFIG_64BITS and ${load-y} in CKSEG0 >> cflags-y += -msym32 >> endif >> >> what do you think ? > > I do not see enough of justification for -msym32 to be forced. > It gives good default behaviours without both user's intervention or configuration: if CONFIG_64BITS ifndef sym32 if load-y in XKPHYS sym32 = '' [1] elif load-y in CKSEG0 sym32 = '-msym32' [2] else if sym32 eq 'yes' sym32 = '-msym32' [3] endef fi cflags-y += $(sym32) [1] since there is no reason to add '-msym32' and it would generate wrong code anyways. [2] since it's used by all platforms to generate smaller code. Warn if this option is not supported by the tool chains. [3] if you really want to generate code loaded in CKSEG0 without -msym32 switch you could always do: $ make sym32=no IMHO, for normal users, this case is probably a configuration bug and that's the reason we should request for a user to ask for it explicitly. -- Franck From ddaney@avtrex.com Thu Feb 1 17:02:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 17:02:35 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:5014 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20038939AbXBARC3 (ORCPT ); Thu, 1 Feb 2007 17:02:29 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 6B4E12985D0; Thu, 1 Feb 2007 12:01:51 -0500 (EST) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Thu, 1 Feb 2007 12:01:51 -0500 (EST) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 1 Feb 2007 09:01:50 -0800 Message-ID: <45C21CFE.9060804@avtrex.com> Date: Thu, 01 Feb 2007 09:01:50 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: Question about signal syscalls ! References: <20070201135734.GB12728@linux-mips.org> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 01 Feb 2007 17:01:50.0664 (UTC) FILETIME=[AA7F2480:01C74622] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13884 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > Hi Ralf, > > On 2/1/07, Ralf Baechle wrote: >> The values of those registers need to be preserved so they can later be >> copied into the signal frame. >> > > Let's take for example sys_sigreturn(). In my understanding this > syscall is used automatically when the signal handler returns. At this > time, I don't see the point to save the static registers since they > have been already saved by setup_sigcontext(). > > Actually I don't see why they need to be saved/restored at all... > > Let's say that process P1 sends a signal X to process P2 which has a > handler defined for signal X and assume that the static registers are > not saved at all. > > Signal X is received by P2. The signal handler is now executed in user > mode. At this point what are the values of the static registers ? I > would say they have the same values (let's call this state S) when P2 > got interrupted. Once the signal handler returns into the kernel mode > by executing 'syscall __NR_sigreturn' instructions, static registers > still have state S and this state is normally preserved during > sys_sigreturn syscall execution. So when resuming the normal execution > of P2, the static registers have the correct values. > > What am I missing ? I don't think *any* registers *need* to be saved on sys_sigreturn(). The values in sigcontext on the user stack associated with the system call are all used instead of the actual register values. David Daney From ralf@linux-mips.org Thu Feb 1 18:10:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 18:10:32 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:11452 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038962AbXBASKb (ORCPT ); Thu, 1 Feb 2007 18:10:31 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l11IATVo018480; Thu, 1 Feb 2007 18:10:29 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l11IASdV018479; Thu, 1 Feb 2007 18:10:28 GMT Date: Thu, 1 Feb 2007 18:10:28 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips Subject: Re: Question about signal syscalls ! Message-ID: <20070201181028.GA16964@linux-mips.org> References: <20070201135734.GB12728@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13885 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 01, 2007 at 03:54:40PM +0100, Franck Bui-Huu wrote: > Let's take for example sys_sigreturn(). In my understanding this > syscall is used automatically when the signal handler returns. At this > time, I don't see the point to save the static registers since they > have been already saved by setup_sigcontext(). > > Actually I don't see why they need to be saved/restored at all... There is no need. Seems you found a harmless but longstanding but introduced by c40738a70f3e02e8554b78af334dc95356a78989. Ralf From mattjreimer@gmail.com Thu Feb 1 18:19:14 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 01 Feb 2007 18:19:18 +0000 (GMT) Received: from an-out-0708.google.com ([209.85.132.240]:21900 "EHLO an-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S20038962AbXBASTO (ORCPT ); Thu, 1 Feb 2007 18:19:14 +0000 Received: by an-out-0708.google.com with SMTP id c8so402997ana for ; Thu, 01 Feb 2007 10:19:12 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NxZwV5fA/hOundN27tL+DIZz2UORFMDQQWJ5O2eIuwiow3bCC7BcEjQG7/WAOXuHekdh71xuycAhap+88kQ/MVa7SOv/wua9B1WQEg0CLMfgHWHywyvJO6zpJquXQAu0WQ+SDv0aS65q4eu0PEwV7myZeb7zpBFP6GS2yeeK3nc= Received: by 10.78.170.17 with SMTP id s17mr551380hue.1170353948628; Thu, 01 Feb 2007 10:19:08 -0800 (PST) Received: by 10.78.184.6 with HTTP; Thu, 1 Feb 2007 10:19:08 -0800 (PST) Message-ID: Date: Thu, 1 Feb 2007 10:19:08 -0800 From: "Matt Reimer" To: "Rodolfo Giometti" Subject: Re: Advice on battery support [was: Advice on APM-EMU reunion] Cc: "Paul Mundt" , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-mips@linux-mips.org In-Reply-To: <20070201095904.GE8882@enneenne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070129230755.GA8705@enneenne.com> <20070130010055.GA15907@linux-sh.org> <20070201095904.GE8882@enneenne.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13886 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mattjreimer@gmail.com Precedence: bulk X-list: linux-mips On 2/1/07, Rodolfo Giometti wrote: > > Ok, starting from these patches I'd like to add a "battery support" to > the kernel. > > What I suppose to do is a new class with a proper methods useful to > collect several info on battery status, such as get_ac_line_status() > get_battery_status(), get_battery_flags(), > get_remaining_battery_life() and so on. Wasn't there recently a big discussion on lkml about a battery class? Matt From wim.vanderschelden@gmail.com Fri Feb 2 00:47:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 00:47:08 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.173]:52231 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20039020AbXBBArB (ORCPT ); Fri, 2 Feb 2007 00:47:01 +0000 Received: by ug-out-1314.google.com with SMTP id 40so687262uga for ; Thu, 01 Feb 2007 16:46:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:user-agent:mime-version:to:subject:content-type:content-transfer-encoding; b=E3rc5LW8ddgiVfkkuCrpVkm0pnCXr7u7EJfRbGM7I4dP+EItiFOxGIOQKQQ41cgdF8ClDhwVsYlCPt4OQj/R8oJ2QFh3ABWIrwuEYK9+1NZ0+M3S3gF/nlsW74C60++r05QqNZFNWnPE2o8S55fqE1AIS/wK4g817TlKdhtsY14= Received: by 10.67.22.14 with SMTP id z14mr3580281ugi.1170377161356; Thu, 01 Feb 2007 16:46:01 -0800 (PST) Received: from ?192.168.2.101? ( [81.164.103.166]) by mx.google.com with ESMTP id h1sm3590317ugf.2007.02.01.16.46.00; Thu, 01 Feb 2007 16:46:01 -0800 (PST) Message-ID: <45C289C9.3010409@gmail.com> Date: Fri, 02 Feb 2007 01:46:01 +0100 From: Wim Vander Schelden User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Linux on the MobilePro 7xx Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13887 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wim.vanderschelden@gmail.com Precedence: bulk X-list: linux-mips Hi, I just purchased a MobilePro 770 and I intend to port linux to it. It runs on a VR4121 CPU, is there already some support in linux-mips for that? I found some stuff on the net, but it all uses 2.4 kernels, and I would rather get a 2.6 going. Anyone who knows a little bit more about the subject is welcome to comment, Wim -- Wim Vander Schelden Bachelor Computer Science, University Ghent http://nanoblog.ath.cx My weblog, powered by Ruby and BSD licensed. From mendoza.ricardo@gmail.com Fri Feb 2 01:33:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 01:33:26 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.186]:8534 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20039028AbXBBBdW (ORCPT ); Fri, 2 Feb 2007 01:33:22 +0000 Received: by nf-out-0910.google.com with SMTP id l24so998822nfc for ; Thu, 01 Feb 2007 17:32:22 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ot/hPfPPYQrptRtbXLkclKfE2v93KX+NR6VspjtnZjdp5FK57Wl3UtuSvuhOMxSQBupxEAwEcn+2rtiDShTOvKnNQGoZv+zChUjpThjhcrQKrupVyU2R2ZYiS0LkliLpHtIZmwv5mUlW8bYHEPc02VqEQk8U5ANGvcjCrfNfFPU= Received: by 10.49.13.19 with SMTP id q19mr5644616nfi.1170379941865; Thu, 01 Feb 2007 17:32:21 -0800 (PST) Received: by 10.49.66.16 with HTTP; Thu, 1 Feb 2007 17:32:21 -0800 (PST) Message-ID: <816d36d30702011732p60b73fe8w1c7a14ee07a3a748@mail.gmail.com> Date: Thu, 1 Feb 2007 21:32:21 -0400 From: "Ricardo Mendoza" To: "Wim Vander Schelden" Subject: Re: Linux on the MobilePro 7xx Cc: linux-mips@linux-mips.org In-Reply-To: <45C289C9.3010409@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45C289C9.3010409@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13888 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mendoza.ricardo@gmail.com Precedence: bulk X-list: linux-mips On 2/1/07, Wim Vander Schelden wrote: > Hi, > > I just purchased a MobilePro 770 and I intend to port linux to it. It > runs on a VR4121 CPU, is there already some support in linux-mips for that? > > I found some stuff on the net, but it all uses 2.4 kernels, and I would > rather get a 2.6 going. > > Anyone who knows a little bit more about the subject is welcome to comment, > > Wim Hi Wim, The VR41XX branch is pretty much fully supported in the kernel, thanks to Yoichi Yuasa's work. You just need to make some board setup code for the MP and you should be ready to boot a kernel on it. On the current linux-mips tree there is NO support for neither fb, pcmcia, touchscreen or keyboard for the MP; there are, however, some drivers for fb, tpanel and keyb written somewhere, just look for them. PCMCIA is broken due to i82365 legacy way of sorting irq's. Taking a look at old linux-vr code for 2.4 tree might help to give you an idea on whats causing the problem. Ricardo From mano@roarinelk.homelinux.net Fri Feb 2 06:14:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 06:15:03 +0000 (GMT) Received: from fnoeppeil48.netpark.at ([217.175.205.176]:44815 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S20038999AbXBBGO6 (ORCPT ); Fri, 2 Feb 2007 06:14:58 +0000 Received: (qmail 23692 invoked by uid 1000); 2 Feb 2007 07:13:57 +0100 Date: Fri, 2 Feb 2007 07:13:56 +0100 From: Manuel Lauss To: linux-mips@linux-mips.org Subject: 2.6.20-rc: au1x irqs broken Message-ID: <20070202061356.GA23661@roarinelk.homelinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13889 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mano@roarinelk.homelinux.net Precedence: bulk X-list: linux-mips Hello, mips-git commit 1603b5aca14f15b34848fb5594d0c7b6333b99144 broke au1x irqs. The kernel boots; however it is not able to mount nfsroot. Reverting the arch/mips/au1000/common/irq.c bits of the above commit fixes it. Thanks, -- ml. From ydq.mips@gmail.com Fri Feb 2 06:21:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 06:21:45 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.185]:62086 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038697AbXBBGVl (ORCPT ); Fri, 2 Feb 2007 06:21:41 +0000 Received: by nf-out-0910.google.com with SMTP id l24so1049159nfc for ; Thu, 01 Feb 2007 22:20:40 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:mime-version:content-type; b=pRuC6xlKpRlsBgNl+a7loxRjRKohRMaE919k9bV+Zs8/oKHd3ZQKz8hshd60xth8qW+uZntTapqvov2eU6mtFhQWRyzfZRloU6RZRGO+kVA0GUEnFOAge3joCDsFOl0cRCbJPVYl/P7WppHJz5xiJwHIuBnml1Ux8bhE9vNr7tI= Received: by 10.82.136.4 with SMTP id j4mr1072778bud.1170397240062; Thu, 01 Feb 2007 22:20:40 -0800 (PST) Received: by 10.82.126.7 with HTTP; Thu, 1 Feb 2007 22:20:39 -0800 (PST) Message-ID: <1af677f80702012220w4c2bd04dj5ed9cdf366ea23c5@mail.gmail.com> Date: Fri, 2 Feb 2007 14:20:39 +0800 From: "Dequan Yang" To: linux-mips@linux-mips.org Subject: Kernel system call problem Cc: qit@haier-ic.com MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_20906_15207972.1170397239963" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13890 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ydq.mips@gmail.com Precedence: bulk X-list: linux-mips ------=_Part_20906_15207972.1170397239963 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I'm porting Linux 2.6.12 to a MIPS 4KEC based SOC. I have done some essential setup work,including CPU setup, board setup, interrupt initialization, page table setup, etc. In breaf, it can go through the kernel startup code in "main.c" until it try to open "/sbin/init " file, here is the source code: if (execute_command) run_init_process(execute_command); run_init_process("/sbin/init"); run_init_process("/etc/init"); run_init_process("/bin/init"); run_init_process("/bin/sh"); " run_init_process(execute_command);"calls "execve " which is a system call, then the kernel stopped without any information. In trap_init( ), it has already installed exception vector,and I cann't find the problem, can anyone give me some advices? Thank you very much! YDQ ------=_Part_20906_15207972.1170397239963 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,

I'm porting Linux 2.6.12 to a MIPS 4KEC based SOC.
I have done some essential setup work,including CPU setup,
board setup, interrupt initialization, page table setup, etc.
In breaf, it can go through the kernel startup code in " main.c"
until it try to open "/sbin/init " file, here is the source code:

if (execute_command)
        run_init_process(execute_command);

    run_init_process("/sbin/init");
    run_init_process("/etc/init");
    run_init_process("/bin/init");
    run_init_process("/bin/sh");

" run_init_process(execute_command);"calls "execve "
which is a system call, then the kernel stopped without any information.
In trap_init( ), it has already installed exception vector,and I cann't
find the problem, can anyone give me some advices?
Thank you very much!

YDQ

------=_Part_20906_15207972.1170397239963-- From anemo@mba.ocn.ne.jp Fri Feb 2 07:19:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 07:19:27 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:56318 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039070AbXBBHTX (ORCPT ); Fri, 2 Feb 2007 07:19:23 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Fri, 2 Feb 2007 16:19:22 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 73AE34209E; Fri, 2 Feb 2007 16:18:58 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 6838620606; Fri, 2 Feb 2007 16:18:58 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l127IvW0040407; Fri, 2 Feb 2007 16:18:57 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 02 Feb 2007 16:18:57 +0900 (JST) Message-Id: <20070202.161857.55145886.nemoto@toshiba-tops.co.jp> To: mano@roarinelk.homelinux.net Cc: linux-mips@linux-mips.org Subject: Re: 2.6.20-rc: au1x irqs broken From: Atsushi Nemoto In-Reply-To: <20070202061356.GA23661@roarinelk.homelinux.net> References: <20070202061356.GA23661@roarinelk.homelinux.net> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13891 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Fri, 2 Feb 2007 07:13:56 +0100, Manuel Lauss wrote: > mips-git commit 1603b5aca14f15b34848fb5594d0c7b6333b99144 broke > au1x irqs. The kernel boots; however it is not able to > mount nfsroot. Reverting the arch/mips/au1000/common/irq.c > bits of the above commit fixes it. Thank you for report. But I can not see how that change break au1x. You are using au1000_eth driver, and the driver use level irq, right? Does reverting just only this part work? static struct irq_chip level_irq_type = { .typename = "Au1000 Level", - .startup = startup_irq, - .shutdown = shutdown_irq, - .enable = local_enable_irq, - .disable = local_disable_irq, .ack = mask_and_ack_level_irq, + .mask = local_disable_irq, + .mask_ack = mask_and_ack_level_irq, + .unmask = local_enable_irq, .end = end_irq, }; And if it was work, does reverting only 4 lines removal part work? --- Atsushi Nemoto From mano@roarinelk.homelinux.net Fri Feb 2 07:54:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 07:54:33 +0000 (GMT) Received: from fnoeppeil48.netpark.at ([217.175.205.176]:40462 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S20039080AbXBBHy3 (ORCPT ); Fri, 2 Feb 2007 07:54:29 +0000 Received: (qmail 23852 invoked by uid 1000); 2 Feb 2007 08:53:28 +0100 Date: Fri, 2 Feb 2007 08:53:28 +0100 From: Manuel Lauss To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: 2.6.20-rc: au1x irqs broken Message-ID: <20070202075328.GB23737@roarinelk.homelinux.net> References: <20070202061356.GA23661@roarinelk.homelinux.net> <20070202.161857.55145886.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202.161857.55145886.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13892 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mano@roarinelk.homelinux.net Precedence: bulk X-list: linux-mips On Fri, Feb 02, 2007 at 04:18:57PM +0900, Atsushi Nemoto wrote: > On Fri, 2 Feb 2007 07:13:56 +0100, Manuel Lauss wrote: > > mips-git commit 1603b5aca14f15b34848fb5594d0c7b6333b99144 broke > > au1x irqs. The kernel boots; however it is not able to > > mount nfsroot. Reverting the arch/mips/au1000/common/irq.c > > bits of the above commit fixes it. > > Thank you for report. But I can not see how that change break au1x. I'm sorry, it was my fault. For some reason I commented out all the .ack/.end fields in the irq_chip descriptions to make an earlier -rc boot. With these fields integrated again it works as expected (although I'm still unsure why the .ack/.end are required at all. Shouldn't mask/unmask/mask_ack be enough? [for non-pb1000]) Sorry for the noise! Thanks, -- ml. From vagabon.xyz@gmail.com Fri Feb 2 08:55:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 08:55:12 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.227]:10908 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039085AbXBBIzI (ORCPT ); Fri, 2 Feb 2007 08:55:08 +0000 Received: by qb-out-0506.google.com with SMTP id e12so113653qba for ; Fri, 02 Feb 2007 00:54:06 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=flzg7reEl1jrC2oWaZxSEiko8xJef0Fb1IBKYIsR1nnBUfRP0aGnxeY3H/VLjr/7MJFr6w7iEQPYtA74J/I5iRaVt8lN2qi+Ug3lQcve1pUQn+NtdT2Exmp0C4hxRpgzs/IUU9Gwes4cgfliRymKZK9qHJu4mSeAK6/VTI1pD+0= Received: by 10.114.161.11 with SMTP id j11mr273696wae.1170406445963; Fri, 02 Feb 2007 00:54:05 -0800 (PST) Received: by 10.114.134.16 with HTTP; Fri, 2 Feb 2007 00:54:05 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2007 09:54:05 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: Question about signal syscalls ! Cc: linux-mips In-Reply-To: <20070201181028.GA16964@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <20070201181028.GA16964@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13893 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/1/07, Ralf Baechle wrote: > On Thu, Feb 01, 2007 at 03:54:40PM +0100, Franck Bui-Huu wrote: > > > Let's take for example sys_sigreturn(). In my understanding this > > syscall is used automatically when the signal handler returns. At this > > time, I don't see the point to save the static registers since they > > have been already saved by setup_sigcontext(). > > > > Actually I don't see why they need to be saved/restored at all... > > There is no need. Seems you found a harmless but longstanding but > introduced by c40738a70f3e02e8554b78af334dc95356a78989. > OK. Just to be sure about what you meant, there are currently 2 places where we save s0-s7 regs. One in setup_sigcontext() and one done by save_static_function(). Do you mean that both savings are useless ? It's actually what I'm thinking and if so setup_sigcontext()/restore_sigcontext() have a harmless bug too. -- Franck From vagabon.xyz@gmail.com Fri Feb 2 08:56:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 08:57:02 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.236]:60580 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039086AbXBBI46 (ORCPT ); Fri, 2 Feb 2007 08:56:58 +0000 Received: by qb-out-0506.google.com with SMTP id e12so113770qba for ; Fri, 02 Feb 2007 00:55:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=nfb8DKdEYRncnV4ht3h3MG22TzrbqpBznfJSA+qYmhxOCxn2ily4ZY6KNzj/zVhE5usKZ5YqXdS/Jrlvfw1YIfIqe4W4afu3Re/QjZXGAJIDMWPLy+X7/mNOEmgMgQimbQ5kc71iSXewfxId1Li7sHXmPwOrgjVRs+4kOXa4niQ= Received: by 10.114.110.1 with SMTP id i1mr276788wac.1170406557073; Fri, 02 Feb 2007 00:55:57 -0800 (PST) Received: by 10.114.134.16 with HTTP; Fri, 2 Feb 2007 00:55:56 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2007 09:55:56 +0100 From: "Franck Bui-Huu" To: "David Daney" Subject: Re: Question about signal syscalls ! Cc: "Ralf Baechle" , linux-mips In-Reply-To: <45C21CFE.9060804@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13894 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/1/07, David Daney wrote: > I don't think *any* registers *need* to be saved on sys_sigreturn(). > The values in sigcontext on the user stack associated with the system > call are all used instead of the actual register values. > Sorry but I don't understand what you mean. Could you explain ? Thanks -- Franck From mano@roarinelk.homelinux.net Fri Feb 2 09:59:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 09:59:20 +0000 (GMT) Received: from fnoeppeil48.netpark.at ([217.175.205.176]:23571 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S20039092AbXBBJ7P (ORCPT ); Fri, 2 Feb 2007 09:59:15 +0000 Received: (qmail 24012 invoked by uid 1000); 2 Feb 2007 10:58:14 +0100 Date: Fri, 2 Feb 2007 10:58:14 +0100 From: Manuel Lauss To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: 2.6.20-rc: au1x irqs broken Message-ID: <20070202095814.GA23967@roarinelk.homelinux.net> References: <20070202061356.GA23661@roarinelk.homelinux.net> <20070202.161857.55145886.nemoto@toshiba-tops.co.jp> <20070202075328.GB23737@roarinelk.homelinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202075328.GB23737@roarinelk.homelinux.net> User-Agent: Mutt/1.5.11 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13895 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mano@roarinelk.homelinux.net Precedence: bulk X-list: linux-mips On Fri, Feb 02, 2007 at 08:53:28AM +0100, Manuel Lauss wrote: > On Fri, Feb 02, 2007 at 04:18:57PM +0900, Atsushi Nemoto wrote: > > On Fri, 2 Feb 2007 07:13:56 +0100, Manuel Lauss wrote: > > > mips-git commit 1603b5aca14f15b34848fb5594d0c7b6333b99144 broke > > > au1x irqs. The kernel boots; however it is not able to > > > mount nfsroot. Reverting the arch/mips/au1000/common/irq.c > > > bits of the above commit fixes it. > > > > Thank you for report. But I can not see how that change break au1x. > > I'm sorry, it was my fault. For some reason I commented out all the > .ack/.end fields in the irq_chip descriptions to make an earlier Here's what tripped me up. I switched au1x over to use the kernel flow handlers, and forgot to undo all of it. rediffed against 2.6.20-rc7 diff -Naurp linux-2.6.20-rc7/arch/mips/au1000/common/irq.c linux-2.6.20-rc7-work/arch/mips/au1000/common/irq.c --- linux-2.6.20-rc7/arch/mips/au1000/common/irq.c 2007-02-01 15:04:35.601983000 +0100 +++ linux-2.6.20-rc7-work/arch/mips/au1000/common/irq.c 2007-02-02 11:23:35.251983000 +0100 @@ -70,7 +70,6 @@ extern irq_cpustat_t irq_stat [NR_CPUS]; extern void mips_timer_interrupt(void); static void setup_local_irq(unsigned int irq, int type, int int_req); -static void end_irq(unsigned int irq_nr); static inline void mask_and_ack_level_irq(unsigned int irq_nr); static inline void mask_and_ack_rise_edge_irq(unsigned int irq_nr); static inline void mask_and_ack_fall_edge_irq(unsigned int irq_nr); @@ -111,7 +109,7 @@ inline void local_disable_irq(unsigned i } -static inline void mask_and_ack_rise_edge_irq(unsigned int irq_nr) +static void mask_and_ack_rise_edge_irq(unsigned int irq_nr) { if (irq_nr > AU1000_LAST_INTC0_INT) { au_writel(1<<(irq_nr-32), IC1_RISINGCLR); @@ -125,7 +123,7 @@ static inline void mask_and_ack_rise_edg } -static inline void mask_and_ack_fall_edge_irq(unsigned int irq_nr) +static void mask_and_ack_fall_edge_irq(unsigned int irq_nr) { if (irq_nr > AU1000_LAST_INTC0_INT) { au_writel(1<<(irq_nr-32), IC1_FALLINGCLR); @@ -139,7 +137,7 @@ static inline void mask_and_ack_fall_edg } -static inline void mask_and_ack_either_edge_irq(unsigned int irq_nr) +static void mask_and_ack_either_edge_irq(unsigned int irq_nr) { /* This may assume that we don't get interrupts from * both edges at once, or if we do, that we don't care. @@ -158,7 +156,7 @@ static inline void mask_and_ack_either_e } -static inline void mask_and_ack_level_irq(unsigned int irq_nr) +static void mask_and_ack_level_irq(unsigned int irq_nr) { local_disable_irq(irq_nr); @@ -172,20 +170,6 @@ static inline void mask_and_ack_level_ir return; } - -static void end_irq(unsigned int irq_nr) -{ - if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))) { - local_enable_irq(irq_nr); - } -#if defined(CONFIG_MIPS_PB1000) - if (irq_nr == AU1000_GPIO_15) { - au_writel(0x4000, PB1000_MDR); /* enable int */ - au_sync(); - } -#endif -} - unsigned long save_local_and_disable(int controller) { int i; @@ -233,39 +217,31 @@ void restore_local_and_enable(int contro static struct irq_chip rise_edge_irq_type = { - .typename = "Au1000 Rise Edge", - .ack = mask_and_ack_rise_edge_irq, + .name = "Au1000", .mask = local_disable_irq, .mask_ack = mask_and_ack_rise_edge_irq, .unmask = local_enable_irq, - .end = end_irq, }; static struct irq_chip fall_edge_irq_type = { - .typename = "Au1000 Fall Edge", - .ack = mask_and_ack_fall_edge_irq, + .name = "Au1000", .mask = local_disable_irq, .mask_ack = mask_and_ack_fall_edge_irq, .unmask = local_enable_irq, - .end = end_irq, }; static struct irq_chip either_edge_irq_type = { - .typename = "Au1000 Rise or Fall Edge", - .ack = mask_and_ack_either_edge_irq, + .name = "Au1000", .mask = local_disable_irq, .mask_ack = mask_and_ack_either_edge_irq, .unmask = local_enable_irq, - .end = end_irq, }; static struct irq_chip level_irq_type = { - .typename = "Au1000 Level", - .ack = mask_and_ack_level_irq, + .name = "Au1000", .mask = local_disable_irq, .mask_ack = mask_and_ack_level_irq, .unmask = local_enable_irq, - .end = end_irq, }; #ifdef CONFIG_PM @@ -309,31 +285,31 @@ static void setup_local_irq(unsigned int au_writel(1<<(irq_nr-32), IC1_CFG2CLR); au_writel(1<<(irq_nr-32), IC1_CFG1CLR); au_writel(1<<(irq_nr-32), IC1_CFG0SET); - set_irq_chip(irq_nr, &rise_edge_irq_type); + set_irq_chip_and_handler_name(irq_nr, &rise_edge_irq_type, handle_edge_irq, "riseedge"); break; case INTC_INT_FALL_EDGE: /* 0:1:0 */ au_writel(1<<(irq_nr-32), IC1_CFG2CLR); au_writel(1<<(irq_nr-32), IC1_CFG1SET); au_writel(1<<(irq_nr-32), IC1_CFG0CLR); - set_irq_chip(irq_nr, &fall_edge_irq_type); + set_irq_chip_and_handler_name(irq_nr, &fall_edge_irq_type, handle_edge_irq, "falledge"); break; case INTC_INT_RISE_AND_FALL_EDGE: /* 0:1:1 */ au_writel(1<<(irq_nr-32), IC1_CFG2CLR); au_writel(1<<(irq_nr-32), IC1_CFG1SET); au_writel(1<<(irq_nr-32), IC1_CFG0SET); - set_irq_chip(irq_nr, &either_edge_irq_type); + set_irq_chip_and_handler_name(irq_nr, &either_edge_irq_type, handle_edge_irq, "bothedge"); break; case INTC_INT_HIGH_LEVEL: /* 1:0:1 */ au_writel(1<<(irq_nr-32), IC1_CFG2SET); au_writel(1<<(irq_nr-32), IC1_CFG1CLR); au_writel(1<<(irq_nr-32), IC1_CFG0SET); - set_irq_chip(irq_nr, &level_irq_type); + set_irq_chip_and_handler_name(irq_nr, &level_irq_type, handle_level_irq, "highlevel"); break; case INTC_INT_LOW_LEVEL: /* 1:1:0 */ au_writel(1<<(irq_nr-32), IC1_CFG2SET); au_writel(1<<(irq_nr-32), IC1_CFG1SET); au_writel(1<<(irq_nr-32), IC1_CFG0CLR); - set_irq_chip(irq_nr, &level_irq_type); + set_irq_chip_and_handler_name(irq_nr, &level_irq_type, handle_level_irq, "lowlevel"); break; case INTC_INT_DISABLED: /* 0:0:0 */ au_writel(1<<(irq_nr-32), IC1_CFG0CLR); @@ -361,31 +337,31 @@ static void setup_local_irq(unsigned int au_writel(1<name); + seq_printf(p, "-%-8s", irq_desc[i].name); seq_printf(p, " %s", action->name); for (action=action->next; action; action = action->next) From sergio@amilda.org Fri Feb 2 13:44:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 13:44:32 +0000 (GMT) Received: from www.pc-net.at ([193.238.157.29]:63430 "EHLO MrWeb01.pc-net.at") by ftp.linux-mips.org with ESMTP id S20039131AbXBBNo2 (ORCPT ); Fri, 2 Feb 2007 13:44:28 +0000 Received: from localhost (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id A8087215ED2 for ; Fri, 2 Feb 2007 14:43:52 +0100 (CET) Received: from MrWeb01.pc-net.at ([127.0.0.1]) by localhost (MrWeb01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 10781-03 for ; Fri, 2 Feb 2007 14:43:46 +0100 (CET) Received: from www.amilda.org (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 8D776215EC8 for ; Fri, 2 Feb 2007 14:43:36 +0100 (CET) Received: from 201.240.249.124 (SquirrelMail authenticated user amilda0001) by www.amilda.org with HTTP; Fri, 2 Feb 2007 08:43:46 -0500 (PET) Message-ID: <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> In-Reply-To: <45C1FE3D.8080304@wp.pl> References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> Date: Fri, 2 Feb 2007 08:43:46 -0500 (PET) Subject: Re: Advice needed. From: "Sergio Aguayo" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.6-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pc-net.at Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13896 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sergio@amilda.org Precedence: bulk X-list: linux-mips > Thanks, i'll look at this (just finished downloading source). But my > question was NOT concerning GENERATING image (that part > of toolchain works, so let it be), but FLasing it. Normally done by webs > app. And as i see in Amilda, it uses the same scheme -> webs-buried C > function. And I would have an alternative, because of: first -> have no > source for webs-buried functions supplied by Edimax, so I have only > choice of using built binary no chance to simply add some functionality, > second -> webs is quite heavyweight, approx 450kb -> it is a lot on > system with 2M Flash expanded to 5M Ramdisk. > The flash memory is represented under Linux as a block device driven by the mtd driver. Therefore it behaves as a normal block device that can be read or written to. Basically, webs does a write to that block device. Earlier versions of the source code released by Edimax included the webs functions. I think the source download is getting more and more useless on every revision. Remember that the whole ramdisk (which has data of less than 3MB) is BZIP2 compressed, and it is concatenated with the kernel and then compressed in GZIP. That makes 450KB not-so-big in 2MB. > BTW maybe someone reading this knows what Edimax devices have 4M flash? > check this: http://www.linux-mips.org/wiki/Adm5120 Sergio From ralf@linux-mips.org Fri Feb 2 14:45:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 14:45:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:48551 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039165AbXBBOpV (ORCPT ); Fri, 2 Feb 2007 14:45:21 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l12EjFS5007337; Fri, 2 Feb 2007 14:45:17 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l12EjFMW007336; Fri, 2 Feb 2007 14:45:15 GMT Date: Fri, 2 Feb 2007 14:45:15 +0000 From: Ralf Baechle To: Manuel Lauss Cc: linux-mips@linux-mips.org Subject: Re: 2.6.20-rc: au1x irqs broken Message-ID: <20070202144515.GA6278@linux-mips.org> References: <20070202061356.GA23661@roarinelk.homelinux.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070202061356.GA23661@roarinelk.homelinux.net> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13897 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 02, 2007 at 07:13:56AM +0100, Manuel Lauss wrote: > mips-git commit 1603b5aca14f15b34848fb5594d0c7b6333b99144 broke There is no commit 1603b5aca14f15b34848fb5594d0c7b6333b99144 ... Ralf From ddaney@avtrex.com Fri Feb 2 16:05:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 16:05:33 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:10398 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20039182AbXBBQFa (ORCPT ); Fri, 2 Feb 2007 16:05:30 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id A80C82981F0; Fri, 2 Feb 2007 11:04:49 -0500 (EST) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 2 Feb 2007 11:04:49 -0500 (EST) Received: from [127.0.0.1] ([192.168.7.229]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 08:04:48 -0800 Message-ID: <45C3611D.7000702@avtrex.com> Date: Fri, 02 Feb 2007 08:04:45 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: Question about signal syscalls ! References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 16:04:48.0100 (UTC) FILETIME=[DCE71240:01C746E3] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13898 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > On 2/1/07, David Daney wrote: >> I don't think *any* registers *need* to be saved on sys_sigreturn(). >> The values in sigcontext on the user stack associated with the system >> call are all used instead of the actual register values. >> > > Sorry but I don't understand what you mean. Could you explain ? sys_sigreturn does not return to the caller in the conventional sense. The entire user context (i.e. the value of *all* registers) is replaced with the values stored in the sigcontext structure on the caller's stack. If all registers are being restored from the sigcontext, then there is no need to save the current values of the registers, because they will never be used. David Daney From vagabon.xyz@gmail.com Fri Feb 2 16:37:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 16:37:36 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.238]:25408 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039210AbXBBQhc (ORCPT ); Fri, 2 Feb 2007 16:37:32 +0000 Received: by qb-out-0506.google.com with SMTP id e12so138635qba for ; Fri, 02 Feb 2007 08:36:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=MLf1c2TKqs114cF8FixPEo8CJ2CM2jqWzh9cCSZwdNZRADi8ZgUJ6z+caF9cH337pk8ixSYjF4pbD4eOsLVfG7LT4NgtWRRXZ93LyRWtZgvD0GC3DUjC0usz0XdmHc/feOEgwJx3xJQHXhluuf/i3X5dYGyXPxWt8Cp8QYbQh5Q= Received: by 10.115.78.1 with SMTP id f1mr306594wal.1170434190630; Fri, 02 Feb 2007 08:36:30 -0800 (PST) Received: by 10.114.134.16 with HTTP; Fri, 2 Feb 2007 08:36:30 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2007 17:36:30 +0100 From: "Franck Bui-Huu" To: "David Daney" Subject: Re: Question about signal syscalls ! Cc: "Ralf Baechle" , linux-mips In-Reply-To: <45C3611D.7000702@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13899 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips David Daney wrote: > sys_sigreturn does not return to the caller in the conventional sense. I expect you're talking about this bite of code taken from _sys_sigreturn(): /* * Don't let your children do this ... */ __asm__ __volatile__( "move\t$29, %0\n\t" "j\tsyscall_exit" :/* no outputs */ :"r" (®s)); > The entire user context (i.e. the value of *all* registers) is replaced > with the values stored in the sigcontext structure on the caller's > stack. If all registers are being restored from the sigcontext, then > there is no need to save the current values of the registers, because > they will never be used. > But I don't see where _all_ registers are saved. Only static registers are saved by save_static_function() right before calling _sys_sigreturn() and I agree I don't why we need to save those. And now I'm starting to think that we don't need to save static regs in setup_sigcontext() either... -- Franck From vagabon.xyz@gmail.com Fri Feb 2 16:43:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 16:44:01 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.231]:31381 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039212AbXBBQnz (ORCPT ); Fri, 2 Feb 2007 16:43:55 +0000 Received: by hu-out-0506.google.com with SMTP id 22so344440hug for ; Fri, 02 Feb 2007 08:42:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=Zz3rXuqRL/Y0ptadFza9izdFy/RI6hgXIdzVgRorYgxusvYszuuAzClOZx2VKCWwEnafporBLAPvyhZLrIxuJXAsjvxzwkagbXolfaOOvbhBTApMHwQugMkEPbgmaoy3ZEO7ZY+d6Fq7qiyGNzo7qZHlsOeyRm1oIQ5h9MotAxA= Received: by 10.49.41.18 with SMTP id t18mr6686567nfj.1170434573773; Fri, 02 Feb 2007 08:42:53 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id l38sm15717641nfc.2007.02.02.08.42.52; Fri, 02 Feb 2007 08:42:53 -0800 (PST) Message-ID: <45C369CB.2040400@innova-card.com> Date: Fri, 02 Feb 2007 17:41:47 +0100 User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Franck , Ralf Baechle CC: linux-mips Subject: [RFC] Add basic SMARTMIPS ASE support Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13900 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This patch adds trivial support for SMARTMIPS extension. This extension is currently implemented by 4KS[CD] CPUs. Basically it saves/restores ACX register, which is part of the SMARTMIPS ASE, when needed. This patch does *not* add any support for Smartmips MMU features. Futhermore this patch does not add explicit support for 4KS[CD] CPUs since they are respectively mips32 and mips32r2 compliant. So with the current processor configuration, a platform that has such CPUs needs to select both configs: CPU_HAS_SMARTMIPS SYS_HAS_CPU_MIPS32_R[12] This is due to the processor configuration which is mixing up all the architecture variants and the processor types. The drawback of this, is that we currently pass '-march=mips32' option to gcc when building a kernel instead of '-march=4ksc' for 4KSC case. This can lead to a kernel image a little bit bigger than required. Signed-off-by: Franck Bui-Huu --- Ralf, Here's the basic support for SMARTMIPS ASE. I'm not very confident with the sigcontext part, if you could double check that would be nice. Please consider, Franck arch/mips/Kconfig | 3 +++ arch/mips/Makefile | 2 ++ arch/mips/kernel/asm-offsets.c | 4 ++++ arch/mips/kernel/ptrace.c | 10 ++++++++++ arch/mips/kernel/ptrace32.c | 10 ++++++++++ arch/mips/kernel/signal.c | 7 +++++++ arch/mips/kernel/signal32.c | 7 +++++++ arch/mips/kernel/traps.c | 3 +++ include/asm-mips/ptrace.h | 4 ++++ include/asm-mips/sigcontext.h | 6 ++++-- include/asm-mips/stackframe.h | 30 ++++++++++++++++++++++++------ 11 files changed, 78 insertions(+), 8 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index da26de5..652ec23 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1633,6 +1633,9 @@ config CPU_HAS_LLSC config CPU_HAS_WB bool +config CPU_HAS_SMARTMIPS + bool + # # Vectored interrupt mode is an R2 feature # diff --git a/arch/mips/Makefile b/arch/mips/Makefile index d1b026a..d31fe0d 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -103,6 +103,8 @@ predef-le += -DMIPSEL -D_MIPSEL -D__MIPSEL -D__MIPSEL__ cflags-$(CONFIG_CPU_BIG_ENDIAN) += $(shell $(CC) -dumpmachine |grep -q 'mips.*el-.*' && echo -EB $(undef-all) $(predef-be)) cflags-$(CONFIG_CPU_LITTLE_ENDIAN) += $(shell $(CC) -dumpmachine |grep -q 'mips.*el-.*' || echo -EL $(undef-all) $(predef-le)) +cflags-$(CONFIG_CPU_HAS_SMARTMIPS) += $(call cc-option,-msmartmips) + cflags-$(CONFIG_SB1XXX_CORELIS) += $(call cc-option,-mno-sched-prolog) \ -fno-omit-frame-pointer diff --git a/arch/mips/kernel/asm-offsets.c b/arch/mips/kernel/asm-offsets.c index ff88b06..c97dd46 100644 --- a/arch/mips/kernel/asm-offsets.c +++ b/arch/mips/kernel/asm-offsets.c @@ -64,6 +64,9 @@ void output_ptreg_defines(void) offset("#define PT_R31 ", struct pt_regs, regs[31]); offset("#define PT_LO ", struct pt_regs, lo); offset("#define PT_HI ", struct pt_regs, hi); +#ifdef CONFIG_CPU_HAS_SMARTMIPS + offset("#define PT_ACX ", struct pt_regs, acx); +#endif offset("#define PT_EPC ", struct pt_regs, cp0_epc); offset("#define PT_BVADDR ", struct pt_regs, cp0_badvaddr); offset("#define PT_STATUS ", struct pt_regs, cp0_status); @@ -250,6 +253,7 @@ void output_sc_defines(void) text("/* Linux sigcontext offsets. */"); offset("#define SC_REGS ", struct sigcontext, sc_regs); offset("#define SC_FPREGS ", struct sigcontext, sc_fpregs); + offset("#define SC_ACX ", struct sigcontext, sc_acx); offset("#define SC_MDHI ", struct sigcontext, sc_mdhi); offset("#define SC_MDLO ", struct sigcontext, sc_mdlo); offset("#define SC_PC ", struct sigcontext, sc_pc); diff --git a/arch/mips/kernel/ptrace.c b/arch/mips/kernel/ptrace.c index 1fd705a..478355a 100644 --- a/arch/mips/kernel/ptrace.c +++ b/arch/mips/kernel/ptrace.c @@ -236,6 +236,11 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data) case MMLO: tmp = regs->lo; break; +#ifdef CONFIG_CPU_HAS_SMARTMIPS + case ACX: + tmp = regs->acx; + break; +#endif case FPC_CSR: tmp = child->thread.fpu.fcr31; break; @@ -362,6 +367,11 @@ long arch_ptrace(struct task_struct *child, long request, long addr, long data) case MMLO: regs->lo = data; break; +#ifdef CONFIG_CPU_HAS_SMARTMIPS + case ACX: + regs->acx = data; + break; +#endif case FPC_CSR: child->thread.fpu.fcr31 = data; break; diff --git a/arch/mips/kernel/ptrace32.c b/arch/mips/kernel/ptrace32.c index d9a39c1..783f17a 100644 --- a/arch/mips/kernel/ptrace32.c +++ b/arch/mips/kernel/ptrace32.c @@ -165,6 +165,11 @@ asmlinkage int sys32_ptrace(int request, int pid, int addr, int data) case MMLO: tmp = regs->lo; break; +#ifdef CONFIG_CPU_HAS_SMARTMIPS + case ACX: + tmp = regs->acx; + break; +#endif case FPC_CSR: tmp = child->thread.fpu.fcr31; break; @@ -315,6 +320,11 @@ asmlinkage int sys32_ptrace(int request, int pid, int addr, int data) case MMLO: regs->lo = data; break; +#ifdef CONFIG_CPU_HAS_SMARTMIPS + case ACX: + regs->acx = data; + break; +#endif case FPC_CSR: child->thread.fpu.fcr31 = data; break; diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index d3f6b0a..e6237c0 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -71,6 +71,9 @@ int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) for (i = 1; i < 32; i++) err |= __put_user(regs->regs[i], &sc->sc_regs[i]); +#ifdef CONFIG_CPU_HAS_SMARTMIPS + err |= __put_user(regs->acx, &sc->sc_acx); +#endif err |= __put_user(regs->hi, &sc->sc_mdhi); err |= __put_user(regs->lo, &sc->sc_mdlo); if (cpu_has_dsp) { @@ -114,6 +117,10 @@ int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) current_thread_info()->restart_block.fn = do_no_restart_syscall; err |= __get_user(regs->cp0_epc, &sc->sc_pc); + +#ifdef CONFIG_CPU_HAS_SMARTMIPS + err |= __get_user(regs->acx, &sc->sc_acx); +#endif err |= __get_user(regs->hi, &sc->sc_mdhi); err |= __get_user(regs->lo, &sc->sc_mdlo); if (cpu_has_dsp) { diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 0994d6e..ec3af4c 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -175,6 +175,9 @@ static int setup_sigcontext32(struct pt_regs *regs, for (i = 1; i < 32; i++) err |= __put_user(regs->regs[i], &sc->sc_regs[i]); +#ifdef CONFIG_CPU_HAS_SMARTMIPS + err |= __put_user(regs->acx, &sc->sc_acx); +#endif err |= __put_user(regs->hi, &sc->sc_mdhi); err |= __put_user(regs->lo, &sc->sc_mdlo); if (cpu_has_dsp) { @@ -219,6 +222,10 @@ static int restore_sigcontext32(struct pt_regs *regs, current_thread_info()->restart_block.fn = do_no_restart_syscall; err |= __get_user(regs->cp0_epc, &sc->sc_pc); + +#ifdef CONFIG_CPU_HAS_SMARTMIPS + err |= __get_user(regs->acx, &sc->sc_acx); +#endif err |= __get_user(regs->hi, &sc->sc_mdhi); err |= __get_user(regs->lo, &sc->sc_mdlo); if (cpu_has_dsp) { diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 2a932ca..2167c55 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -229,6 +229,9 @@ void show_regs(struct pt_regs *regs) printk("\n"); } +#ifdef CONFIG_CPU_HAS_SMARTMIPS + printk("Acx : %0*lx\n", field, regs->acx); +#endif printk("Hi : %0*lx\n", field, regs->hi); printk("Lo : %0*lx\n", field, regs->lo); diff --git a/include/asm-mips/ptrace.h b/include/asm-mips/ptrace.h index 8a1f2b6..1906938 100644 --- a/include/asm-mips/ptrace.h +++ b/include/asm-mips/ptrace.h @@ -21,6 +21,7 @@ #define FPC_EIR 70 #define DSP_BASE 71 /* 3 more hi / lo register pairs */ #define DSP_CONTROL 77 +#define ACX 78 /* * This struct defines the way the registers are stored on the stack during a @@ -39,6 +40,9 @@ struct pt_regs { unsigned long cp0_status; unsigned long hi; unsigned long lo; +#ifdef CONFIG_CPU_HAS_SMARTMIPS + unsigned long acx; +#endif unsigned long cp0_badvaddr; unsigned long cp0_cause; unsigned long cp0_epc; diff --git a/include/asm-mips/sigcontext.h b/include/asm-mips/sigcontext.h index cefa657..c3cf365 100644 --- a/include/asm-mips/sigcontext.h +++ b/include/asm-mips/sigcontext.h @@ -23,7 +23,7 @@ struct sigcontext { unsigned long long sc_pc; unsigned long long sc_regs[32]; unsigned long long sc_fpregs[32]; - unsigned int sc_ownedfp; /* Unused */ + unsigned int sc_acx; /* Was sc_ownedfp */ unsigned int sc_fpc_csr; unsigned int sc_fpc_eir; /* Unused */ unsigned int sc_used_math; @@ -51,10 +51,12 @@ struct sigcontext { * binary compatibility - no prisoners. * DSP ASE in 2.6.12-rc4. Turn sc_mdhi and sc_mdlo into an array of four * entries, add sc_dsp and sc_reserved for padding. No prisoners. + * SMARTMIPS ASE in 2.6.20. Add sc_acx. */ struct sigcontext { unsigned long sc_regs[32]; unsigned long sc_fpregs[32]; + unsigned long sc_acx; unsigned long sc_mdhi; unsigned long sc_hi1; unsigned long sc_hi2; @@ -80,7 +82,7 @@ struct sigcontext32 { __u64 sc_pc; __u64 sc_regs[32]; __u64 sc_fpregs[32]; - __u32 sc_ownedfp; /* Unused */ + __u32 sc_acx; /* Was sc_ownedfp */ __u32 sc_fpc_csr; __u32 sc_fpc_eir; /* Unused */ __u32 sc_used_math; diff --git a/include/asm-mips/stackframe.h b/include/asm-mips/stackframe.h index 1fae5dc..7afa1fd 100644 --- a/include/asm-mips/stackframe.h +++ b/include/asm-mips/stackframe.h @@ -29,16 +29,25 @@ .endm .macro SAVE_TEMP +#ifdef CONFIG_CPU_HAS_SMARTMIPS + mflhxu v1 + LONG_S v1, PT_LO(sp) + mflhxu v1 + LONG_S v1, PT_HI(sp) + mflhxu v1 + LONG_S v1, PT_ACX(sp) +#else mfhi v1 + LONG_S v1, PT_HI(sp) + mflo v1 + LONG_S v1, PT_LO(sp) +#endif #ifdef CONFIG_32BIT LONG_S $8, PT_R8(sp) LONG_S $9, PT_R9(sp) #endif - LONG_S v1, PT_HI(sp) - mflo v1 LONG_S $10, PT_R10(sp) LONG_S $11, PT_R11(sp) - LONG_S v1, PT_LO(sp) LONG_S $12, PT_R12(sp) LONG_S $13, PT_R13(sp) LONG_S $14, PT_R14(sp) @@ -182,16 +191,25 @@ .endm .macro RESTORE_TEMP +#ifdef CONFIG_CPU_HAS_SMARTMIPS + LONG_L $24, PT_ACX(sp) + mtlhx $24 + LONG_L $24, PT_HI(sp) + mtlhx $24 LONG_L $24, PT_LO(sp) + mtlhx $24 +#else + LONG_L $24, PT_LO(sp) + mtlo $24 + LONG_L $24, PT_HI(sp) + mthi $24 +#endif #ifdef CONFIG_32BIT LONG_L $8, PT_R8(sp) LONG_L $9, PT_R9(sp) #endif - mtlo $24 - LONG_L $24, PT_HI(sp) LONG_L $10, PT_R10(sp) LONG_L $11, PT_R11(sp) - mthi $24 LONG_L $12, PT_R12(sp) LONG_L $13, PT_R13(sp) LONG_L $14, PT_R14(sp) -- 1.4.4.3.ge6d4 From drow@nevyn.them.org Fri Feb 2 16:57:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 16:57:14 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:61630 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S20039212AbXBBQ5K (ORCPT ); Fri, 2 Feb 2007 16:57:10 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HD1fg-00080G-IA; Fri, 02 Feb 2007 11:53:56 -0500 Date: Fri, 2 Feb 2007 11:53:56 -0500 From: Daniel Jacobowitz To: Franck Bui-Huu Cc: David Daney , Ralf Baechle , linux-mips Subject: Re: Question about signal syscalls ! Message-ID: <20070202165356.GA30584@nevyn.them.org> References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13901 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips On Fri, Feb 02, 2007 at 05:36:30PM +0100, Franck Bui-Huu wrote: > And now I'm starting to think that we don't need to save static regs in > setup_sigcontext() either... It's possible not to (iirc at least one arch does that) but please don't change it now. This is a userland ABI issue; GDB knows that the registers are saved, and there are slots for them in sigcontext/ucontext so it would be unexpected if they were not filled in. Could break things like pth. -- Daniel Jacobowitz CodeSourcery From ddaney@avtrex.com Fri Feb 2 16:57:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 16:57:40 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:41197 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20039221AbXBBQ5V (ORCPT ); Fri, 2 Feb 2007 16:57:21 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id F1072298562; Fri, 2 Feb 2007 11:56:42 -0500 (EST) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 2 Feb 2007 11:56:42 -0500 (EST) Received: from [127.0.0.1] ([192.168.7.229]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 08:56:41 -0800 Message-ID: <45C36D46.5040409@avtrex.com> Date: Fri, 02 Feb 2007 08:56:38 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: Question about signal syscalls ! References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 16:56:41.0626 (UTC) FILETIME=[1CB56FA0:01C746EB] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13902 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Franck Bui-Huu wrote: > David Daney wrote: >> sys_sigreturn does not return to the caller in the conventional sense. > > I expect you're talking about this bite of code taken from > _sys_sigreturn(): > > /* > * Don't let your children do this ... > */ > __asm__ __volatile__( > "move\t$29, %0\n\t" > "j\tsyscall_exit" > :/* no outputs */ > :"r" (®s)); > >> The entire user context (i.e. the value of *all* registers) is replaced >> with the values stored in the sigcontext structure on the caller's >> stack. If all registers are being restored from the sigcontext, then >> there is no need to save the current values of the registers, because >> they will never be used. >> > > But I don't see where _all_ registers are saved. Only static registers > are saved by save_static_function() right before calling > _sys_sigreturn() and I agree I don't why we need to save those. > > And now I'm starting to think that we don't need to save static regs in > setup_sigcontext() either... > All registers *must* be saved in the sigcontext. That is part of the contract the kernel has with user code. On return from an asynchronous signal, *all* registers must contain the same values they had before the process was interrupted. David Daney David Daney From vagabon.xyz@gmail.com Fri Feb 2 19:58:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 19:58:39 +0000 (GMT) Received: from an-out-0708.google.com ([209.85.132.240]:44492 "EHLO an-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S20039258AbXBBT6f (ORCPT ); Fri, 2 Feb 2007 19:58:35 +0000 Received: by an-out-0708.google.com with SMTP id c8so680760ana for ; Fri, 02 Feb 2007 11:58:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BJqwlcZIwgjWRIky8gcBWBnzNj/Oktg/28h3BqsvjtOvCSrYFJ2NFy0KhePCC6ja63AHWK5sFL7FG0Afk+FQ2f6iN35Poh88uTIdhMlQmDfcozQmMl5Kog4IIYA5C+cIUZ4Il+E/42uCPR5UXS30TcMi76yvqs4xsKy/95gc+Dc= Received: by 10.114.108.15 with SMTP id g15mr363744wac.1170446311937; Fri, 02 Feb 2007 11:58:31 -0800 (PST) Received: by 10.114.134.16 with HTTP; Fri, 2 Feb 2007 11:58:31 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2007 20:58:31 +0100 From: "Franck Bui-Huu" To: "David Daney" Subject: Re: Question about signal syscalls ! Cc: "Ralf Baechle" , linux-mips In-Reply-To: <45C36D46.5040409@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13904 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1026 Lines: 31 On 2/2/07, David Daney wrote: > Franck Bui-Huu wrote: > > David Daney wrote: > >> The entire user context (i.e. the value of *all* registers) is replaced > >> with the values stored in the sigcontext structure on the caller's > >> stack. If all registers are being restored from the sigcontext, then > >> there is no need to save the current values of the registers, because > >> they will never be used. > >> > > Again, why do you think that all values of the registers are saved on sys_sigreturn() ? > > And now I'm starting to think that we don't need to save static regs in > > setup_sigcontext() either... > > > All registers *must* be saved in the sigcontext. That is part of the > contract the kernel has with user code. > I'm just talking about _static_ registers which are s0-s7... > On return from an asynchronous signal, *all* registers must contain the > same values they had before the process was interrupted. > yes I agree and I've never said the contrary. -- Franck From vagabon.xyz@gmail.com Fri Feb 2 20:03:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 20:03:43 +0000 (GMT) Received: from an-out-0708.google.com ([209.85.132.246]:46298 "EHLO an-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S20039260AbXBBUDi (ORCPT ); Fri, 2 Feb 2007 20:03:38 +0000 Received: by an-out-0708.google.com with SMTP id c8so682312ana for ; Fri, 02 Feb 2007 12:03:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=WT+HOnxfb/3orNcYsgu2OFpC/lXzsve5k/eqjW4rwlRIbUyoTA9/K0IOFjhjHM3rczD4M/yd4i/WPydebYlZpkpGQxriz8Gm2EdwIWvFH4tuSUkrl+ZkgtRSMpG5LhucPE6wONXKEyljugPYTmsSeOaEI9wLrKJ9zCzath1oha8= Received: by 10.114.60.19 with SMTP id i19mr376249waa.1170446613315; Fri, 02 Feb 2007 12:03:33 -0800 (PST) Received: by 10.114.134.16 with HTTP; Fri, 2 Feb 2007 12:03:33 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2007 21:03:33 +0100 From: "Franck Bui-Huu" To: "Daniel Jacobowitz" Subject: Re: Question about signal syscalls ! Cc: "David Daney" , "Ralf Baechle" , linux-mips In-Reply-To: <20070202165356.GA30584@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <20070202165356.GA30584@nevyn.them.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13905 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 715 Lines: 23 On 2/2/07, Daniel Jacobowitz wrote: > On Fri, Feb 02, 2007 at 05:36:30PM +0100, Franck Bui-Huu wrote: > > And now I'm starting to think that we don't need to save static regs in > > setup_sigcontext() either... > > It's possible not to (iirc at least one arch does that) but please can you tell which one ? > don't change it now. This is a userland ABI issue; GDB knows that the don't worry I don't want to change anything, I'm just trying to understand. > registers are saved, and there are slots for them in > sigcontext/ucontext so it would be unexpected if they were not filled > in. Could break things like pth. > ok it's a good point to keep in mind. thanks -- Franck From vagabon.xyz@gmail.com Fri Feb 2 20:18:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 20:18:43 +0000 (GMT) Received: from an-out-0708.google.com ([209.85.132.251]:39686 "EHLO an-out-0708.google.com") by ftp.linux-mips.org with ESMTP id S20039264AbXBBUSh (ORCPT ); Fri, 2 Feb 2007 20:18:37 +0000 Received: by an-out-0708.google.com with SMTP id c8so686729ana for ; Fri, 02 Feb 2007 12:18:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HufPr8SAQGtodUjxdB89Yx09Wtlo1N4ZvYfpppK7tLH4pUk1zb/9vzQw7grHekg/1v+cNn0JhaHesFoEZuvdvBRRdJmHCkoQAc8enRFVDU5eOMj/AuRntejDGO+6t6s8ttx7kiaOyW1UGrEPcj9ypCmeTdBgLp+miAoKANlKm+8= Received: by 10.114.185.8 with SMTP id i8mr394085waf.1170447514538; Fri, 02 Feb 2007 12:18:34 -0800 (PST) Received: by 10.114.134.16 with HTTP; Fri, 2 Feb 2007 12:18:34 -0800 (PST) Message-ID: Date: Fri, 2 Feb 2007 21:18:34 +0100 From: "Franck Bui-Huu" To: "Daniel Jacobowitz" Subject: Re: Question about signal syscalls ! Cc: "David Daney" , "Ralf Baechle" , linux-mips In-Reply-To: <20070202165356.GA30584@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <20070202165356.GA30584@nevyn.them.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13906 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 413 Lines: 13 On 2/2/07, Daniel Jacobowitz wrote: > On Fri, Feb 02, 2007 at 05:36:30PM +0100, Franck Bui-Huu wrote: > > And now I'm starting to think that we don't need to save static regs in > > setup_sigcontext() either... > > It's possible not to (iirc at least one arch does that) but please > crazy idea: do you think it could be possible not to when dealing with interrupts ? -- Franck From ddaney@avtrex.com Fri Feb 2 20:41:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 20:41:54 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:42726 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20039264AbXBBUls (ORCPT ); Fri, 2 Feb 2007 20:41:48 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id 5034E298572; Fri, 2 Feb 2007 15:41:08 -0500 (EST) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Fri, 2 Feb 2007 15:41:08 -0500 (EST) Received: from [192.168.7.26] ([192.168.7.26]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Fri, 2 Feb 2007 12:41:07 -0800 Message-ID: <45C3A1E3.8010802@avtrex.com> Date: Fri, 02 Feb 2007 12:41:07 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: Franck Bui-Huu Cc: Ralf Baechle , linux-mips Subject: Re: Question about signal syscalls ! References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 02 Feb 2007 20:41:07.0505 (UTC) FILETIME=[76FF8210:01C7470A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13907 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Content-Length: 1405 Lines: 42 Franck Bui-Huu wrote: > On 2/2/07, David Daney wrote: >> Franck Bui-Huu wrote: >> > David Daney wrote: >> >> The entire user context (i.e. the value of *all* registers) is >> replaced >> >> with the values stored in the sigcontext structure on the caller's >> >> stack. If all registers are being restored from the sigcontext, then >> >> there is no need to save the current values of the registers, because >> >> they will never be used. >> >> >> > > > Again, why do you think that all values of the registers are saved on > sys_sigreturn() ? I don't think that. I don't think I ever said that. > > >> > And now I'm starting to think that we don't need to save static regs in >> > setup_sigcontext() either... >> > >> All registers *must* be saved in the sigcontext. That is part of the >> contract the kernel has with user code. >> > > I'm just talking about _static_ registers which are s0-s7... > >> On return from an asynchronous signal, *all* registers must contain the >> same values they had before the process was interrupted. >> > > yes I agree and I've never said the contrary. I thought you were suggesting not saving s0-s7. If you don't save them, you cannot restore them. And they have to be restored from the sigcontext in the user's address space. This allows user space signal handlers to emulate trapping instructions, and the like. David Daney From giometti@enneenne.com Fri Feb 2 21:30:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 21:30:51 +0000 (GMT) Received: from 81-174-11-161.f5.ngi.it ([81.174.11.161]:31673 "EHLO mail.enneenne.com") by ftp.linux-mips.org with ESMTP id S20039278AbXBBVar (ORCPT ); Fri, 2 Feb 2007 21:30:47 +0000 Received: from zaigor.enneenne.com ([192.168.32.1]) by mail.enneenne.com with esmtp (Exim 4.50) id 1HD5vz-0007dP-Vx; Fri, 02 Feb 2007 22:27:07 +0100 Received: from giometti by zaigor.enneenne.com with local (Exim 4.63) (envelope-from ) id 1HD5wb-00073t-MA; Fri, 02 Feb 2007 22:27:41 +0100 Date: Fri, 2 Feb 2007 22:27:41 +0100 From: Rodolfo Giometti To: Paul Mundt , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-mips@linux-mips.org Message-ID: <20070202212741.GH8882@enneenne.com> References: <20070129230755.GA8705@enneenne.com> <20070130010055.GA15907@linux-sh.org> <20070201095904.GE8882@enneenne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070201095904.GE8882@enneenne.com> Organization: GNU/Linux Device Drivers, Embedded Systems and Courses X-PGP-Key: gpg --keyserver keyserver.linux.it --recv-keys D25A5633 User-Agent: Mutt/1.5.13 (2006-08-11) X-SA-Exim-Connect-IP: 192.168.32.1 X-SA-Exim-Mail-From: giometti@enneenne.com Subject: [PATCH 1/1] APM-EMULATION: apm_get_power_status() should be NULL on init [was: Advice on battery support] X-SA-Exim-Version: 4.2 (built Thu, 03 Mar 2005 10:44:12 +0100) X-SA-Exim-Scanned: Yes (on mail.enneenne.com) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13908 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: giometti@enneenne.com Precedence: bulk X-list: linux-mips Content-Length: 1047 Lines: 36 APM-EMULATION: apm_get_power_status() should be NULL on init. Signed-off-by: Rodolfo Giometti --- If the function apm_get_info() do like this: static int apm_get_info(char *buf, char **start, off_t fpos, int length) { struct apm_power_info info; char *units; int ret; info.ac_line_status = 0xff; info.battery_status = 0xff; info.battery_flag = 0xff; info.battery_life = -1; info.time = -1; info.units = -1; if (apm_get_power_status) apm_get_power_status(&info); ... we shouldn't set: static void __apm_get_power_status(struct apm_power_info *info) { } void (*apm_get_power_status)(struct apm_power_info *) = __apm_get_power_status; otherwise the check is not needed. Furthermore setting the function to NULL signals that the apm-emulation layer is not already assigned (I found this very useful for my apm-emulation battery_class support). From pavel@ucw.cz Fri Feb 2 21:36:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 02 Feb 2007 21:36:11 +0000 (GMT) Received: from gprs189-60.eurotel.cz ([160.218.189.60]:34017 "EHLO amd.ucw.cz") by ftp.linux-mips.org with ESMTP id S20039266AbXBBVgH (ORCPT ); Fri, 2 Feb 2007 21:36:07 +0000 Received: by amd.ucw.cz (Postfix, from userid 8) id 7E6E08060; Fri, 2 Feb 2007 22:35:23 +0100 (CET) Date: Fri, 2 Feb 2007 22:35:23 +0100 From: Pavel Machek To: Rodolfo Giometti Cc: Paul Mundt , linux-kernel@vger.kernel.org, linux-arm-kernel@lists.arm.linux.org.uk, linux-mips@linux-mips.org Subject: Re: Advice on battery support [was: Advice on APM-EMU reunion] Message-ID: <20070202213523.GA5089@elf.ucw.cz> References: <20070129230755.GA8705@enneenne.com> <20070130010055.GA15907@linux-sh.org> <20070201095904.GE8882@enneenne.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070201095904.GE8882@enneenne.com> X-Warning: Reading this can be dangerous to your mental health. User-Agent: Mutt/1.5.11+cvs20060126 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13909 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: pavel@ucw.cz Precedence: bulk X-list: linux-mips Content-Length: 1208 Lines: 32 Hi! > > However, it has since been reposted: > > > > http://article.gmane.org/gmane.linux.kernel/485833 > > http://article.gmane.org/gmane.linux.kernel/485834 > > http://article.gmane.org/gmane.linux.kernel/485835 > > http://article.gmane.org/gmane.linux.kernel/485837 > > > > and merged back in to -mm. This is all post 2.6.20 stuff, though.. > > Ok, starting from these patches I'd like to add a "battery support" to > the kernel. > > What I suppose to do is a new class with a proper methods useful to > collect several info on battery status, such as get_ac_line_status() > get_battery_status(), get_battery_flags(), > get_remaining_battery_life() and so on. > > The output will be APM-like into file "/proc/apm" (one line per > battery, or just the "main"/first one?) so that existing applications > continue to work and under sysfs into "/sysfs/class/battery". > > Is it sane? :) Yep. Notice that designing /sysfs/class/battery is not going to be easy, and that some work was already done in context of olpc project. Search the mailing lists... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html From sergio@amilda.org Sat Feb 3 05:58:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Feb 2007 05:58:32 +0000 (GMT) Received: from www.pc-net.at ([193.238.157.29]:30411 "EHLO MrWeb01.pc-net.at") by ftp.linux-mips.org with ESMTP id S20037475AbXBCF60 (ORCPT ); Sat, 3 Feb 2007 05:58:26 +0000 Received: from localhost (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 19B2F215ECC for ; Sat, 3 Feb 2007 06:57:51 +0100 (CET) Received: from MrWeb01.pc-net.at ([127.0.0.1]) by localhost (MrWeb01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 00413-06 for ; Sat, 3 Feb 2007 06:57:48 +0100 (CET) Received: from www.amilda.org (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 74793215EC8 for ; Sat, 3 Feb 2007 06:57:38 +0100 (CET) Received: from 201.230.45.190 (SquirrelMail authenticated user amilda0001) by www.amilda.org with HTTP; Sat, 3 Feb 2007 00:57:48 -0500 (PET) Message-ID: <50812.201.230.45.190.1170482268.squirrel@www.amilda.org> In-Reply-To: <45C3BB23.2070309@wp.pl> References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> <45C3BB23.2070309@wp.pl> Date: Sat, 3 Feb 2007 00:57:48 -0500 (PET) Subject: Re: Advice needed. From: "Sergio Aguayo" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.6-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pc-net.at Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13910 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sergio@amilda.org Precedence: bulk X-list: linux-mips Content-Length: 840 Lines: 30 > > >>check this: http://www.linux-mips.org/wiki/Adm5120 >> >> >> > Nice ;) > > Sergio, > 1). I am trying now to port the flash utility to BR-6204Wg (different > data structure), as of now i have succeded to read part of > hardware-related settings -> nic0, nic1, wlan-mac. As I finish I'll send > you a copy of related changes needed. Are you talking about the configuration structure? If so, it varies between model to model. AMiLDA itself uses a totally different configuration which may very from version to version. > 2). I have compiled webs server as-is from Amilda, it compiles, but when > started just returns with no output. I will investigate this. > That means that webs encountered an error starting up. Usually it is due to another webs instance already running or another process that has port 80 opened. Sergio From zzh.hust@gmail.com Sat Feb 3 09:32:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Feb 2007 09:33:01 +0000 (GMT) Received: from nf-out-0910.google.com ([64.233.182.189]:5282 "EHLO nf-out-0910.google.com") by ftp.linux-mips.org with ESMTP id S20038409AbXBCJc5 (ORCPT ); Sat, 3 Feb 2007 09:32:57 +0000 Received: by nf-out-0910.google.com with SMTP id l24so1377436nfc for ; Sat, 03 Feb 2007 01:31:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=EKNex/PC8bxEjq6DWlqPDBQhNuyI84nHIOt62PDYrcqVw+2Ta+z2J7EuJIt+OKKBnyzxH0RtoHS8TI/k2oN9hB5kxEiBj/kZhLU05ZE3uBCuBIdJ43yINEPBWLmv6f302zLhKnag412f4/J1HQh0ISe9ikUL3C+Zc5PFwYCPWHc= Received: by 10.82.152.16 with SMTP id z16mr1506124bud.1170495116407; Sat, 03 Feb 2007 01:31:56 -0800 (PST) Received: by 10.82.178.4 with HTTP; Sat, 3 Feb 2007 01:31:56 -0800 (PST) Message-ID: <50c9a2250702030131x7ea1331ay29acdd1190208173@mail.gmail.com> Date: Sat, 3 Feb 2007 17:31:56 +0800 From: zhuzhenhua To: linux-mips Subject: whatis the connection with sysctl and "bad magic number for tty struct ..." ? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13911 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1332 Lines: 53 hi all: i am working on a mips borad with linux-2.6.14. and my board boot up from an initrd and then switch to Nand FLASH as root dev. it also add a power control entry like the /arch/mips/common/power.c do. as follow #define CTL_ACPI 9999 #define ACPI_S1_SLP_TYP 19 #define ACPI_SLEEP 21 static struct ctl_table pm_table[] = { {ACPI_S1_SLP_TYP, "suspend", NULL, 0, 0600, NULL, &pm_do_suspend}, {ACPI_SLEEP, "sleep", NULL, 0, 0600, NULL, &pm_do_sleep}, {CTL_ACPI, "freq", NULL, 0, 0600, NULL, &pm_do_freq}, {0} }; static struct ctl_table pm_dir_table[] = { {CTL_ACPI, "pm", NULL, 0, 0555, pm_table}, {0} }; /* * Initialize power interface */ static int __init pm_init(void) { register_sysctl_table(pm_dir_table, 1); return 0; } __initcall(pm_init); they had worked well before. but this week, out nand flash driver change the driver to new code. and when use the same kernel to bootup ,when switch rootfs by /linuxrc. it get messages "bad magic number for tty struct ..." . but if i manual insmod my flash driiver, it works.and also if ii remove the "register_sysctl_table(pm_dir_table, 1)", it works too. so what will cause this situation? (i have check the flash driver code, not find special code). BTW: the initrd is made with busybox instead of nash. thanks for any hints Best Regards zhuzhenhua From tsbogend@alpha.franken.de Sat Feb 3 13:09:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Feb 2007 13:09:22 +0000 (GMT) Received: from elvis.franken.de ([193.175.24.41]:51415 "EHLO elvis.franken.de") by ftp.linux-mips.org with ESMTP id S20038757AbXBCNJR (ORCPT ); Sat, 3 Feb 2007 13:09:17 +0000 Received: from uucp (helo=solo.franken.de) by elvis.franken.de with local-bsmtp (Exim 3.36 #1) id 1HDKam-0003Kg-00; Sat, 03 Feb 2007 14:06:08 +0100 Received: by solo.franken.de (Postfix, from userid 1000) id 48B42C2E0E; Sat, 3 Feb 2007 14:06:10 +0100 (CET) Date: Sat, 3 Feb 2007 14:06:10 +0100 To: linux-mips@linux-mips.org, ralf@linux-mips.org Subject: PATCH: Fix mc146818_decode_year Message-ID: <20070203130610.GA18062@alpha.franken.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.9i From: tsbogend@alpha.franken.de (Thomas Bogendoerfer) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13912 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tsbogend@alpha.franken.de Precedence: bulk X-list: linux-mips Content-Length: 3108 Lines: 78 Big endian RMs uses a different mc146818_decode_year than little endian RMs Correct mc146818_decode_year for years before 2000 Signed-off-by: Thomas Bogendoerfer --- include/asm-mips/mach-atlas/mc146818rtc.h | 2 +- include/asm-mips/mach-generic/mc146818rtc.h | 2 +- include/asm-mips/mach-mips/mc146818rtc.h | 2 +- include/asm-mips/mach-rm/mc146818rtc.h | 10 +++++++--- 4 files changed, 10 insertions(+), 6 deletions(-) diff --git a/include/asm-mips/mach-atlas/mc146818rtc.h b/include/asm-mips/mach-atlas/mc146818rtc.h index a73a569..51d337e 100644 --- a/include/asm-mips/mach-atlas/mc146818rtc.h +++ b/include/asm-mips/mach-atlas/mc146818rtc.h @@ -55,6 +55,6 @@ static inline void CMOS_WRITE(unsigned char data, unsigned long addr) #define RTC_ALWAYS_BCD 0 -#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1970) +#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1900) #endif /* __ASM_MACH_ATLAS_MC146818RTC_H */ diff --git a/include/asm-mips/mach-generic/mc146818rtc.h b/include/asm-mips/mach-generic/mc146818rtc.h index 90c2e6f..0b9a942 100644 --- a/include/asm-mips/mach-generic/mc146818rtc.h +++ b/include/asm-mips/mach-generic/mc146818rtc.h @@ -30,7 +30,7 @@ static inline void CMOS_WRITE(unsigned char data, unsigned long addr) #define RTC_ALWAYS_BCD 1 #ifndef mc146818_decode_year -#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1970) +#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1900) #endif #endif /* __ASM_MACH_GENERIC_MC146818RTC_H */ diff --git a/include/asm-mips/mach-mips/mc146818rtc.h b/include/asm-mips/mach-mips/mc146818rtc.h index 6730ba0..ea612f3 100644 --- a/include/asm-mips/mach-mips/mc146818rtc.h +++ b/include/asm-mips/mach-mips/mc146818rtc.h @@ -43,6 +43,6 @@ static inline void CMOS_WRITE(unsigned char data, unsigned long addr) #define RTC_ALWAYS_BCD 0 -#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1970) +#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1900) #endif /* __ASM_MACH_MALTA_MC146818RTC_H */ diff --git a/include/asm-mips/mach-rm/mc146818rtc.h b/include/asm-mips/mach-rm/mc146818rtc.h index d37ae68..103ae8e 100644 --- a/include/asm-mips/mach-rm/mc146818rtc.h +++ b/include/asm-mips/mach-rm/mc146818rtc.h @@ -7,11 +7,15 @@ * * RTC routines for PC style attached Dallas chip with ARC epoch. */ -#ifndef __ASM_MACH_RM200_MC146818RTC_H -#define __ASM_MACH_RM200_MC146818RTC_H +#ifndef __ASM_MACH_RM_MC146818RTC_H +#define __ASM_MACH_RM_MC146818RTC_H +#if CONFIG_CPU_BIG_ENDIAN +#define mc146818_decode_year(year) ((year) < 70 ? (year) + 2000 : (year) + 1900) +#else #define mc146818_decode_year(year) ((year) + 1980) +#endif #include_next -#endif /* __ASM_MACH_RM200_MC146818RTC_H */ +#endif /* __ASM_MACH_RM_MC146818RTC_H */ -- 1.4.4.3 -- Crap can work. Given enough thrust pigs will fly, but it's not necessary a good idea. [ RFC1925, 2.3 ] From anemo@mba.ocn.ne.jp Sat Feb 3 15:05:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Feb 2007 15:05:05 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:65246 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038798AbXBCPFA (ORCPT ); Sat, 3 Feb 2007 15:05:00 +0000 Received: from localhost (p3165-ipad210funabasi.chiba.ocn.ne.jp [58.88.122.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 732E7B6C5; Sun, 4 Feb 2007 00:03:38 +0900 (JST) Date: Sun, 04 Feb 2007 00:03:38 +0900 (JST) Message-Id: <20070204.000338.21930811.anemo@mba.ocn.ne.jp> To: mano@roarinelk.homelinux.net Cc: linux-mips@linux-mips.org Subject: Re: 2.6.20-rc: au1x irqs broken From: Atsushi Nemoto In-Reply-To: <20070202095814.GA23967@roarinelk.homelinux.net> References: <20070202.161857.55145886.nemoto@toshiba-tops.co.jp> <20070202075328.GB23737@roarinelk.homelinux.net> <20070202095814.GA23967@roarinelk.homelinux.net> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13913 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 3001 Lines: 101 On Fri, 2 Feb 2007 10:58:14 +0100, Manuel Lauss wrote: > Here's what tripped me up. I switched au1x over to use the kernel > flow handlers, and forgot to undo all of it. > > rediffed against 2.6.20-rc7 > > diff -Naurp linux-2.6.20-rc7/arch/mips/au1000/common/irq.c linux-2.6.20-rc7-work/arch/mips/au1000/common/irq.c ... > @@ -172,20 +170,6 @@ static inline void mask_and_ack_level_ir > return; > } > > - > -static void end_irq(unsigned int irq_nr) > -{ > - if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))) { > - local_enable_irq(irq_nr); > - } > -#if defined(CONFIG_MIPS_PB1000) > - if (irq_nr == AU1000_GPIO_15) { > - au_writel(0x4000, PB1000_MDR); /* enable int */ > - au_sync(); > - } > -#endif > -} > - > unsigned long save_local_and_disable(int controller) > { > int i; You are to drop PB1000 support? > @@ -233,39 +217,31 @@ void restore_local_and_enable(int contro > > > static struct irq_chip rise_edge_irq_type = { > - .typename = "Au1000 Rise Edge", > - .ack = mask_and_ack_rise_edge_irq, > + .name = "Au1000", > .mask = local_disable_irq, > .mask_ack = mask_and_ack_rise_edge_irq, > .unmask = local_enable_irq, > - .end = end_irq, > }; > > static struct irq_chip fall_edge_irq_type = { > - .typename = "Au1000 Fall Edge", > - .ack = mask_and_ack_fall_edge_irq, > + .name = "Au1000", > .mask = local_disable_irq, > .mask_ack = mask_and_ack_fall_edge_irq, > .unmask = local_enable_irq, > - .end = end_irq, > }; > > static struct irq_chip either_edge_irq_type = { > - .typename = "Au1000 Rise or Fall Edge", > - .ack = mask_and_ack_either_edge_irq, > + .name = "Au1000", > .mask = local_disable_irq, > .mask_ack = mask_and_ack_either_edge_irq, > .unmask = local_enable_irq, > - .end = end_irq, > }; > > static struct irq_chip level_irq_type = { > - .typename = "Au1000 Level", > - .ack = mask_and_ack_level_irq, > + .name = "Au1000", > .mask = local_disable_irq, > .mask_ack = mask_and_ack_level_irq, > .unmask = local_enable_irq, > - .end = end_irq, > }; > > #ifdef CONFIG_PM .ack entries are required for handle_edge_irq. And if you wanted to unregister an irq handler by set_irq_handler(irq, NULL), .ack will be used even for level flow handler. Also note that typename to name conversion patch is already in queue tree. > diff -Naurp linux-2.6.20-rc7/arch/mips/kernel/irq.c linux-2.6.20-rc7-work/arch/mips/kernel/irq.c > --- linux-2.6.20-rc7/arch/mips/kernel/irq.c 2007-02-01 15:04:35.831983000 +0100 > +++ linux-2.6.20-rc7-work/arch/mips/kernel/irq.c 2007-02-02 11:15:34.201983000 +0100 > @@ -118,6 +118,7 @@ int show_interrupts(struct seq_file *p, > seq_printf(p, "%10u ", kstat_cpu(j).irqs[i]); > #endif > seq_printf(p, " %14s", irq_desc[i].chip->name); > + seq_printf(p, "-%-8s", irq_desc[i].name); > seq_printf(p, " %s", action->name); > > for (action=action->next; action; action = action->next) > irq_desc[i].name might be NULL. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Sat Feb 3 15:58:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Feb 2007 15:58:51 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:10238 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038812AbXBCP6q (ORCPT ); Sat, 3 Feb 2007 15:58:46 +0000 Received: from localhost (p3165-ipad210funabasi.chiba.ocn.ne.jp [58.88.122.165]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A5886B80C; Sun, 4 Feb 2007 00:57:25 +0900 (JST) Date: Sun, 04 Feb 2007 00:57:25 +0900 (JST) Message-Id: <20070204.005725.62338494.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: [PATCH] fix pb1200/irqmap.c and apply some missed patches From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13914 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 1881 Lines: 69 pb1200/irqmap.c had been broken a while due to non-named initializer and had missed some recent IRQ related changes. Apply these commits to this file. [MIPS] IRQ cleanups commit 1603b5aca4f15b34848fb5594d0c7b6333b99144 [MIPS] use generic_handle_irq, handle_level_irq, handle_percpu_irq commit 1417836e81c0ab8f5a0bfeafa90d3eaa41b2a067 [MIPS] Compile __do_IRQ() when really needed commit e77c232cfc6e1250b2916a7c69225d6634d05a49 Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/au1000/pb1200/irqmap.c b/arch/mips/au1000/pb1200/irqmap.c index 91983ba..b73b2d1 100644 --- a/arch/mips/au1000/pb1200/irqmap.c +++ b/arch/mips/au1000/pb1200/irqmap.c @@ -137,33 +137,20 @@ static void pb1200_shutdown_irq( unsigne return; } -static inline void pb1200_mask_and_ack_irq(unsigned int irq_nr) -{ - pb1200_disable_irq( irq_nr ); -} - -static void pb1200_end_irq(unsigned int irq_nr) -{ - if (!(irq_desc[irq_nr].status & (IRQ_DISABLED|IRQ_INPROGRESS))) { - pb1200_enable_irq(irq_nr); - } -} - static struct irq_chip external_irq_type = { #ifdef CONFIG_MIPS_PB1200 - "Pb1200 Ext", + .name = "Pb1200 Ext", #endif #ifdef CONFIG_MIPS_DB1200 - "Db1200 Ext", + .name = "Db1200 Ext", #endif - pb1200_startup_irq, - pb1200_shutdown_irq, - pb1200_enable_irq, - pb1200_disable_irq, - pb1200_mask_and_ack_irq, - pb1200_end_irq, - NULL + .startup = pb1200_startup_irq, + .shutdown = pb1200_shutdown_irq, + .ack = pb1200_disable_irq, + .mask = pb1200_disable_irq, + .mask_ack = pb1200_disable_irq, + .unmask = pb1200_enable_irq, }; void _board_init_irq(void) @@ -172,7 +159,8 @@ void _board_init_irq(void) for (irq_nr = PB1200_INT_BEGIN; irq_nr <= PB1200_INT_END; irq_nr++) { - irq_desc[irq_nr].chip = &external_irq_type; + set_irq_chip_and_handler(irq_nr, &external_irq_type, + handle_level_irq); pb1200_disable_irq(irq_nr); } From mano@roarinelk.homelinux.net Sat Feb 3 20:35:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 03 Feb 2007 20:35:35 +0000 (GMT) Received: from fnoeppeil48.netpark.at ([217.175.205.176]:26632 "EHLO roarinelk.homelinux.net") by ftp.linux-mips.org with ESMTP id S20038926AbXBCUfa (ORCPT ); Sat, 3 Feb 2007 20:35:30 +0000 Received: (qmail 5414 invoked from network); 3 Feb 2007 21:34:28 +0100 Received: from scarran.roarinelk.net (HELO ?192.168.0.242?) (192.168.0.242) by wormhole.roarinelk.net with SMTP; 3 Feb 2007 21:34:28 +0100 Message-ID: <45C4F1B1.3070407@roarinelk.homelinux.net> Date: Sat, 03 Feb 2007 21:33:53 +0100 From: Manuel Lauss User-Agent: Thunderbird/1.0 Mnenhy/0.7 MIME-Version: 1.0 To: Atsushi Nemoto CC: linux-mips@linux-mips.org Subject: Re: 2.6.20-rc: au1x irqs broken References: <20070202.161857.55145886.nemoto@toshiba-tops.co.jp> <20070202075328.GB23737@roarinelk.homelinux.net> <20070202095814.GA23967@roarinelk.homelinux.net> <20070204.000338.21930811.anemo@mba.ocn.ne.jp> In-Reply-To: <20070204.000338.21930811.anemo@mba.ocn.ne.jp> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13915 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mano@roarinelk.homelinux.net Precedence: bulk X-list: linux-mips Content-Length: 339 Lines: 14 Atsushi Nemoto wrote: > You are to drop PB1000 support? I won't submit this patch for inclusion, ever. It was just a test. > .ack entries are required for handle_edge_irq. And if you wanted to > unregister an irq handler by set_irq_handler(irq, NULL), .ack will be > used even for level flow handler. Good to know, Thanks. -- ml. From compudj@krystal.dyndns.org Sun Feb 4 04:18:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Feb 2007 04:18:43 +0000 (GMT) Received: from tomts36.bellnexxia.net ([209.226.175.93]:5113 "EHLO tomts36-srv.bellnexxia.net") by ftp.linux-mips.org with ESMTP id S20027627AbXBDESi (ORCPT ); Sun, 4 Feb 2007 04:18:38 +0000 Received: from krystal.dyndns.org ([67.68.196.179]) by tomts36-srv.bellnexxia.net (InterMail vM.5.01.06.13 201-253-122-130-113-20050324) with ESMTP id <20070204041651.LQAF1862.tomts36-srv.bellnexxia.net@krystal.dyndns.org> for ; Sat, 3 Feb 2007 23:16:51 -0500 Received: from localhost (localhost [127.0.0.1]) (uid 1000) by krystal.dyndns.org with local; Sat, 03 Feb 2007 23:16:51 -0500 id 001C247E.45C55E33.000022E4 Date: Sat, 3 Feb 2007 23:16:51 -0500 From: Mathieu Desnoyers To: linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Subject: [PATCH] ifdef missing in arch/mips/pmc-sierra/yosemite/setup.c Message-ID: <20070204041651.GA8732@Krystal> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Editor: vi X-Info: http://krystal.dyndns.org:8080 X-Operating-System: Linux/2.4.34-grsec (i686) X-Uptime: 23:15:02 up 1 day, 18:23, 2 users, load average: 1.18, 1.05, 1.01 User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13916 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: mathieu.desnoyers@polymtl.ca Precedence: bulk X-list: linux-mips Content-Length: 840 Lines: 28 ifdef missing in arch/mips/pmc-sierra/yosemite/setup.c early_serial_setup is only defined when CONFIG_SERIAL_8250 is set. Applies on 2.6.20-rc7. Signed-off-by: Mathieu Desnoyers --- a/arch/mips/pmc-sierra/yosemite/setup.c +++ b/arch/mips/pmc-sierra/yosemite/setup.c @@ -171,6 +171,7 @@ static void __init py_map_ocd(void) static void __init py_uart_setup(void) { +#ifdef CONFIG_SERIAL_8250 struct uart_port up; /* @@ -188,6 +189,7 @@ static void __init py_uart_setup(void) if (early_serial_setup(&up)) printk(KERN_ERR "Early serial init of port 0 failed\n"); +#endif //CONFIG_SERIAL_8250 } static void __init py_rtc_setup(void) -- OpenPGP public key: http://krystal.dyndns.org:8080/key/compudj.gpg Key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 From ralf@linux-mips.org Sun Feb 4 17:54:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 04 Feb 2007 17:54:34 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:4006 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037679AbXBDRyc (ORCPT ); Sun, 4 Feb 2007 17:54:32 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l14HsVTg015282; Sun, 4 Feb 2007 17:54:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l14HsS79015281; Sun, 4 Feb 2007 17:54:28 GMT Date: Sun, 4 Feb 2007 17:54:28 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] fix pb1200/irqmap.c and apply some missed patches Message-ID: <20070204175428.GA12319@linux-mips.org> References: <20070204.005725.62338494.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070204.005725.62338494.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13917 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 249 Lines: 9 On Sun, Feb 04, 2007 at 12:57:25AM +0900, Atsushi Nemoto wrote: > pb1200/irqmap.c had been broken a while due to non-named initializer > and had missed some recent IRQ related changes. Apply these commits > to this file. Thanks, applied. Ralf From drow@nevyn.them.org Mon Feb 5 00:58:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 00:58:34 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:59828 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S20038780AbXBEA63 (ORCPT ); Mon, 5 Feb 2007 00:58:29 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HDs8a-0000QK-3a; Sun, 04 Feb 2007 19:55:16 -0500 Date: Sun, 4 Feb 2007 19:55:16 -0500 From: Daniel Jacobowitz To: David Daney Cc: Franck Bui-Huu , Ralf Baechle , linux-mips Subject: Re: Question about signal syscalls ! Message-ID: <20070205005516.GA1581@nevyn.them.org> References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> <45C3A1E3.8010802@avtrex.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45C3A1E3.8010802@avtrex.com> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13918 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 608 Lines: 14 On Fri, Feb 02, 2007 at 12:41:07PM -0800, David Daney wrote: > I thought you were suggesting not saving s0-s7. If you don't save them, > you cannot restore them. And they have to be restored from the > sigcontext in the user's address space. This allows user space signal > handlers to emulate trapping instructions, and the like. Not necessarily, because you can trust the signal handler to restore them, and it can save them itself if it needs to. As I said, I think there's at least one architecture which does it this way. I'm afraid I don't know which one. -- Daniel Jacobowitz CodeSourcery From ralf@linux-mips.org Mon Feb 5 01:10:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 01:10:57 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:61373 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039067AbXBEBKz (ORCPT ); Mon, 5 Feb 2007 01:10:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l151AouQ026750; Mon, 5 Feb 2007 01:10:50 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l151AmFV026749; Mon, 5 Feb 2007 01:10:48 GMT Date: Mon, 5 Feb 2007 01:10:48 +0000 From: Ralf Baechle To: Daniel Jacobowitz Cc: David Daney , Franck Bui-Huu , linux-mips Subject: Re: Question about signal syscalls ! Message-ID: <20070205011048.GA26654@linux-mips.org> References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> <45C3A1E3.8010802@avtrex.com> <20070205005516.GA1581@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205005516.GA1581@nevyn.them.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13919 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1093 Lines: 22 On Sun, Feb 04, 2007 at 07:55:16PM -0500, Daniel Jacobowitz wrote: > On Fri, Feb 02, 2007 at 12:41:07PM -0800, David Daney wrote: > > I thought you were suggesting not saving s0-s7. If you don't save them, > > you cannot restore them. And they have to be restored from the > > sigcontext in the user's address space. This allows user space signal > > handlers to emulate trapping instructions, and the like. > > Not necessarily, because you can trust the signal handler to restore > them, and it can save them itself if it needs to. As I said, I think > there's at least one architecture which does it this way. I'm afraid I > don't know which one. Not saving the s-registers into the signal frame would be a neat optimization. It wouldn't only make things a little faster it would also free space in the signal frame which is needed for CPU architecture extensions that have more state to save. I had to burn almost the entire available space for the DSP extensions, so I wonder if we could get GDB to work? The alternative is probably a new version of the sigrestore. Ralf From drow@nevyn.them.org Mon Feb 5 02:30:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 02:30:46 +0000 (GMT) Received: from nevyn.them.org ([66.93.172.17]:35809 "EHLO nevyn.them.org") by ftp.linux-mips.org with ESMTP id S20038718AbXBECam (ORCPT ); Mon, 5 Feb 2007 02:30:42 +0000 Received: from drow by nevyn.them.org with local (Exim 4.63) (envelope-from ) id 1HDtct-0001QZ-Gh; Sun, 04 Feb 2007 21:30:39 -0500 Date: Sun, 4 Feb 2007 21:30:39 -0500 From: Daniel Jacobowitz To: Ralf Baechle Cc: David Daney , Franck Bui-Huu , linux-mips Subject: Re: Question about signal syscalls ! Message-ID: <20070205023039.GA5438@nevyn.them.org> References: <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> <45C3A1E3.8010802@avtrex.com> <20070205005516.GA1581@nevyn.them.org> <20070205011048.GA26654@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205011048.GA26654@linux-mips.org> User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13920 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dan@debian.org Precedence: bulk X-list: linux-mips Content-Length: 990 Lines: 22 On Mon, Feb 05, 2007 at 01:10:48AM +0000, Ralf Baechle wrote: > Not saving the s-registers into the signal frame would be a neat > optimization. It wouldn't only make things a little faster it would > also free space in the signal frame which is needed for CPU > architecture extensions that have more state to save. I had to burn > almost the entire available space for the DSP extensions, so I wonder > if we could get GDB to work? The alternative is probably a new version > of the sigrestore. I'm sure that, if we tried, we could get GDB to work. Every time this comes up I just worry about other things that we don't know about which use the saved information. These structures are just in too many places to change comfortably. If you're worried about DSP extensions, you might want to take a look at the work Nico and I did for ARM in the past year or so; it tags extra register sets in the ucontext. It was a pain to get together though. -- Daniel Jacobowitz CodeSourcery From darwish.07@gmail.com Mon Feb 5 02:43:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 02:43:30 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.173]:35935 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20038990AbXBECnZ (ORCPT ); Mon, 5 Feb 2007 02:43:25 +0000 Received: by ug-out-1314.google.com with SMTP id 40so1300409uga for ; Sun, 04 Feb 2007 18:42:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:date:to:cc:subject:message-id:mime-version:content-type:content-disposition:in-reply-to:user-agent:from; b=OJ+OxNmTatvZWwK17A32rzOGV56gXhAcOHrCLIWPDpHzgqUpHCFMdylN5riApFX/Ej7HE+VTfgTMFvAQ95cFnYgDLmyHyywzLJFlqiAR9m3EcOk7Zkaygl5aYaNlDHD3ocBItIjsCtkjpVluDeF3aI18dcJlRdw+UKMYE14C82k= Received: by 10.67.20.3 with SMTP id x3mr8108577ugi.1170643345058; Sun, 04 Feb 2007 18:42:25 -0800 (PST) Received: from darwish-laptop ( [196.218.207.19]) by mx.google.com with ESMTP id l33sm7666281ugc.2007.02.04.18.42.22; Sun, 04 Feb 2007 18:42:24 -0800 (PST) Received: by darwish-laptop (sSMTP sendmail emulation); Mon, 5 Feb 2007 04:42:11 +0200 Date: Mon, 5 Feb 2007 04:42:11 +0200 To: ralf@linux-mips.org, linux-mips@linux-mips.org Cc: linux-kernel@vger.kernel.org Subject: [PATCH 2.6.20] arch MIPS: user ARRAY_SIZE macro when appropriate Message-ID: <20070205024211.GK18118@Ahmed> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205023935.GG18118@Ahmed> User-Agent: Mutt/1.5.11 From: "Ahmed S. Darwish" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13921 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: darwish.07@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 4104 Lines: 120 Hi all, A patch to use ARRAY_SIZE macro already defined in linux/kernel.h Signed-off-by: Ahmed S. Darwish --- Patch isn't compile checked cause I have no MIPS board at hand. Thanks, diff --git a/arch/mips/jmr3927/rbhma3100/setup.c b/arch/mips/jmr3927/rbhma3100/setup.c index 138f25e..7ca3d6d 100644 --- a/arch/mips/jmr3927/rbhma3100/setup.c +++ b/arch/mips/jmr3927/rbhma3100/setup.c @@ -434,7 +434,7 @@ void __init tx3927_setup(void) /* DMA */ tx3927_dmaptr->mcr = 0; - for (i = 0; i < sizeof(tx3927_dmaptr->ch) / sizeof(tx3927_dmaptr->ch[0]); i++) { + for (i = 0; i < ARRAY_SIZE(tx3927_dmaptr->ch); i++) { /* reset channel */ tx3927_dmaptr->ch[i].ccr = TX3927_DMA_CCR_CHRST; tx3927_dmaptr->ch[i].ccr = 0; diff --git a/arch/mips/arc/identify.c b/arch/mips/arc/identify.c index 3ba7c47..4b90736 100644 --- a/arch/mips/arc/identify.c +++ b/arch/mips/arc/identify.c @@ -77,7 +77,7 @@ static struct smatch * __init string_to_mach(const char *s) { int i; - for (i = 0; i < (sizeof(mach_table) / sizeof (mach_table[0])); i++) { + for (i = 0; i < ARRAY_SIZE(mach_table); i++) { if (!strcmp(s, mach_table[i].arcname)) return &mach_table[i]; } diff --git a/arch/mips/mips-boards/atlas/atlas_int.c b/arch/mips/mips-boards/atlas/atlas_int.c index 43dba6c..4929f4d 100644 --- a/arch/mips/mips-boards/atlas/atlas_int.c +++ b/arch/mips/mips-boards/atlas/atlas_int.c @@ -32,6 +32,7 @@ #include #include #include +#include #include #include @@ -220,7 +221,7 @@ msc_irqmap_t __initdata msc_irqmap[] = { {MSC01C_INT_TMR, MSC01_IRQ_EDGE, 0}, {MSC01C_INT_PCI, MSC01_IRQ_LEVEL, 0}, }; -int __initdata msc_nr_irqs = sizeof(msc_irqmap) / sizeof(*msc_irqmap); +int __initdata msc_nr_irqs = ARRAY_SIZE(msc_irqmap); msc_irqmap_t __initdata msc_eicirqmap[] = { {MSC01E_INT_SW0, MSC01_IRQ_LEVEL, 0}, @@ -231,7 +232,7 @@ msc_irqmap_t __initdata msc_eicirqmap[] = { {MSC01E_INT_PERFCTR, MSC01_IRQ_LEVEL, 0}, {MSC01E_INT_CPUCTR, MSC01_IRQ_LEVEL, 0} }; -int __initdata msc_nr_eicirqs = sizeof(msc_eicirqmap) / sizeof(*msc_eicirqmap); +int __initdata msc_nr_eicirqs = ARRAY_SIZE(msc_eicirqmap); void __init arch_init_irq(void) { diff --git a/arch/mips/mips-boards/malta/malta_int.c b/arch/mips/mips-boards/malta/malta_int.c index 90ad5bf..b28edf5 100644 --- a/arch/mips/mips-boards/malta/malta_int.c +++ b/arch/mips/mips-boards/malta/malta_int.c @@ -27,6 +27,7 @@ #include #include #include +#include #include #include @@ -289,7 +290,7 @@ msc_irqmap_t __initdata msc_irqmap[] = { {MSC01C_INT_TMR, MSC01_IRQ_EDGE, 0}, {MSC01C_INT_PCI, MSC01_IRQ_LEVEL, 0}, }; -int __initdata msc_nr_irqs = sizeof(msc_irqmap)/sizeof(msc_irqmap_t); +int __initdata msc_nr_irqs = ARRAY_SIZE(msc_irqmap); msc_irqmap_t __initdata msc_eicirqmap[] = { {MSC01E_INT_SW0, MSC01_IRQ_LEVEL, 0}, @@ -303,7 +304,7 @@ msc_irqmap_t __initdata msc_eicirqmap[] = { {MSC01E_INT_PERFCTR, MSC01_IRQ_LEVEL, 0}, {MSC01E_INT_CPUCTR, MSC01_IRQ_LEVEL, 0} }; -int __initdata msc_nr_eicirqs = sizeof(msc_eicirqmap)/sizeof(msc_irqmap_t); +int __initdata msc_nr_eicirqs = ARRAY_SIZE(msc_eicirqmap); void __init arch_init_irq(void) { diff --git a/arch/mips/pci/fixup-vr4133.c b/arch/mips/pci/fixup-vr4133.c index 597b897..6e09f38 100644 --- a/arch/mips/pci/fixup-vr4133.c +++ b/arch/mips/pci/fixup-vr4133.c @@ -17,6 +17,7 @@ */ #include #include +#include #include #include @@ -142,7 +143,7 @@ int rockhopper_get_irq(struct pci_dev *dev, u8 pin, u8 slot) if (bus == NULL) return -1; - for (i = 0; i < sizeof (int_map) / sizeof (int_map[0]); i++) { + for (i = 0; i < ARRAY_SIZE(int_map); i++) { if (int_map[i].bus == bus->number && int_map[i].slot == slot) { int line; for (line = 0; line < 4; line++) -- Ahmed S. Darwish http://darwish-07.blogspot.com From ddaney@avtrex.com Mon Feb 5 06:00:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 06:01:03 +0000 (GMT) Received: from smtp1.dnsmadeeasy.com ([205.234.170.134]:27624 "EHLO smtp1.dnsmadeeasy.com") by ftp.linux-mips.org with ESMTP id S20027577AbXBEGAx (ORCPT ); Mon, 5 Feb 2007 06:00:53 +0000 Received: from smtp1.dnsmadeeasy.com (localhost [127.0.0.1]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP id D5FA4297F8B; Mon, 5 Feb 2007 01:00:15 -0500 (EST) X-Authenticated-Name: js.dnsmadeeasy X-Transit-System: In case of SPAM please contact abuse@dnsmadeeasy.com Received: from avtrex.com (unknown [67.116.42.147]) by smtp1.dnsmadeeasy.com (Postfix) with ESMTP; Mon, 5 Feb 2007 01:00:15 -0500 (EST) Received: from [192.168.7.229] ([192.168.7.229]) by avtrex.com with Microsoft SMTPSVC(6.0.3790.1830); Sun, 4 Feb 2007 22:00:13 -0800 Message-ID: <45C6C7F0.7000502@avtrex.com> Date: Sun, 04 Feb 2007 22:00:16 -0800 From: David Daney User-Agent: Thunderbird 1.5.0.9 (X11/20061219) MIME-Version: 1.0 To: Daniel Jacobowitz Cc: Ralf Baechle , Franck Bui-Huu , linux-mips Subject: Re: Question about signal syscalls ! References: <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> <45C3A1E3.8010802@avtrex.com> <20070205005516.GA1581@nevyn.them.org> <20070205011048.GA26654@linux-mips.org> <20070205023039.GA5438@nevyn.them.org> In-Reply-To: <20070205023039.GA5438@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-OriginalArrivalTime: 05 Feb 2007 06:00:13.0728 (UTC) FILETIME=[E6EE6A00:01C748EA] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13922 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ddaney@avtrex.com Precedence: bulk X-list: linux-mips Content-Length: 1202 Lines: 26 Daniel Jacobowitz wrote: > On Mon, Feb 05, 2007 at 01:10:48AM +0000, Ralf Baechle wrote: > >> Not saving the s-registers into the signal frame would be a neat >> optimization. It wouldn't only make things a little faster it would >> also free space in the signal frame which is needed for CPU >> architecture extensions that have more state to save. I had to burn >> almost the entire available space for the DSP extensions, so I wonder >> if we could get GDB to work? The alternative is probably a new version >> of the sigrestore. >> > > I'm sure that, if we tried, we could get GDB to work. Every time this > comes up I just worry about other things that we don't know about which > use the saved information. These structures are just in too many > places to change comfortably. > If you are keeping track, add MD_FALLBACK_FRAME_STATE in libgcc, which allows throwing C++ and java exceptions through signal handlers. If gdb can be made to work, so can libgcc. The thing I worry about is I think people upgrade their kernel much more often than their toolchains. So you could be in a position of having to use a very new GCC. That might make some uncomfortable. David Daney From anemo@mba.ocn.ne.jp Mon Feb 5 07:11:51 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 07:11:55 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:5248 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20027546AbXBEHLv (ORCPT ); Mon, 5 Feb 2007 07:11:51 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Mon, 5 Feb 2007 16:11:48 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 4BD8220500; Mon, 5 Feb 2007 16:11:24 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 409CE2038D; Mon, 5 Feb 2007 16:11:24 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l157BNW0052777; Mon, 5 Feb 2007 16:11:24 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Mon, 05 Feb 2007 16:11:23 +0900 (JST) Message-Id: <20070205.161123.25910611.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [MIPS] Do not allow oprofile to be enabled on SMTC. From: Atsushi Nemoto In-Reply-To: References: X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13923 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 559 Lines: 19 On Fri, 02 Feb 2007 11:18:06 +0000, linux-mips@linux-mips.org wrote: > Author: Ralf Baechle Fri Feb 2 11:13:35 2007 +0000 > Commit: ef9be4f49c0c69d912f9db55fcb3bee5454c6694 > Gitweb: http://www.linux-mips.org/g/linux/ef9be4f4 > Branch: master > > Oprofile cannot work on SMTC due to the limited number of counters. > > Signed-off-by: Ralf Baechle > > --- > > arch/mips/oprofile/Kconfig | 2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) !!MIPS_MT_SMTC means MIPS_MT_SMTC!=n ... --- Atsushi Nemoto From vagabon.xyz@gmail.com Mon Feb 5 09:09:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 09:09:50 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.227]:28631 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037425AbXBEJJq (ORCPT ); Mon, 5 Feb 2007 09:09:46 +0000 Received: by qb-out-0506.google.com with SMTP id e12so499311qba for ; Mon, 05 Feb 2007 01:08:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n2snF/qZM4EW3WYzk0lQdxadWFJ3V15aylBEoYZ+h7NjyLDny71deSI+3PrBLIA7n25G4wSamOmrXriXK06rpgnAUaMpQ/t9PXCqq6vPRFqg5JBKDPgepxR33Dda+4NArhj7OP6BRiaxhMxQTwlf+x2PcUDqN4CSVaqVNxqpZYE= Received: by 10.115.76.1 with SMTP id d1mr571824wal.1170666523584; Mon, 05 Feb 2007 01:08:43 -0800 (PST) Received: by 10.114.136.11 with HTTP; Mon, 5 Feb 2007 01:08:43 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2007 10:08:43 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: Question about signal syscalls ! Cc: "Daniel Jacobowitz" , "David Daney" , linux-mips In-Reply-To: <20070205011048.GA26654@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070201135734.GB12728@linux-mips.org> <45C21CFE.9060804@avtrex.com> <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> <45C3A1E3.8010802@avtrex.com> <20070205005516.GA1581@nevyn.them.org> <20070205011048.GA26654@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13924 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 497 Lines: 11 On 2/5/07, Ralf Baechle wrote: > Not saving the s-registers into the signal frame would be a neat > optimization. It wouldn't only make things a little faster it would Actually it seems to me that setup_sigcontext() is almost completly useless if the signal handler is dealt when returning from a system call since just a very few registers are saved in the 'struct pt_regs' structure. So setup_sigcontext() ends up saving a lot of random values. -- Franck From vagabon.xyz@gmail.com Mon Feb 5 09:18:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 09:18:30 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.229]:8984 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037479AbXBEJS0 (ORCPT ); Mon, 5 Feb 2007 09:18:26 +0000 Received: by qb-out-0506.google.com with SMTP id e12so500519qba for ; Mon, 05 Feb 2007 01:17:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ak7dU5kNPSpeOXrsesvrNkmvqbP9XZzUNuyciDldtNxOR257nTwE5cD3hzBKFOUA3sjDtQVfqi25q0/M6Fyc4klahot6D6RhF0Qg5UiFjNLF2YBxx5sUCIAaHNGIj9E2lQcY9yBcqwDUaQBQCuk3f+/NuvghtTImPcZYCBpK8sw= Received: by 10.114.93.1 with SMTP id q1mr574219wab.1170667044554; Mon, 05 Feb 2007 01:17:24 -0800 (PST) Received: by 10.114.136.11 with HTTP; Mon, 5 Feb 2007 01:17:24 -0800 (PST) Message-ID: Date: Mon, 5 Feb 2007 10:17:24 +0100 From: "Franck Bui-Huu" To: "Daniel Jacobowitz" Subject: Re: Question about signal syscalls ! Cc: "Ralf Baechle" , "David Daney" , linux-mips In-Reply-To: <20070205023039.GA5438@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45C3611D.7000702@avtrex.com> <45C36D46.5040409@avtrex.com> <45C3A1E3.8010802@avtrex.com> <20070205005516.GA1581@nevyn.them.org> <20070205011048.GA26654@linux-mips.org> <20070205023039.GA5438@nevyn.them.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13925 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 784 Lines: 19 On 2/5/07, Daniel Jacobowitz wrote: > I'm sure that, if we tried, we could get GDB to work. Every time this > comes up I just worry about other things that we don't know about which > use the saved information. These structures are just in too many > places to change comfortably. > It seems pretty dangerous if some tools use this saved hw context. Because if the signal handler is handled during a return from a system call (not from interrupt) then most information in the saved information are random... Well maybe we could just make a new version sig context functions which does not save/restore static registers and make it an disabled by default. That would let some people to play with and to see if it break some user tools ? -- Franck From Thomas.Koeller@baslerweb.com Mon Feb 5 10:39:07 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 10:39:11 +0000 (GMT) Received: from mail.baslerweb.com ([145.253.187.130]:3292 "EHLO mail.baslerweb.com") by ftp.linux-mips.org with ESMTP id S20037553AbXBEKjH convert rfc822-to-8bit (ORCPT ); Mon, 5 Feb 2007 10:39:07 +0000 Received: (from smtpd@127.0.0.1) by mail.baslerweb.com (8.13.4/8.13.4) id l15AZvlH029069 for ; Mon, 5 Feb 2007 11:35:57 +0100 Received: from unknown [172.16.20.75] by gateway id /processing/kwmfBmIy; Mon Feb 05 11:35:56 2007 MIME-Version: 1.0 X-MimeOLE: Produced By Microsoft Exchange V6.5 Date: Mon, 5 Feb 2007 11:35:55 +0100 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [MIPS] Remove Basler Excite support Thread-Index: AcdInJgP4CEg03flRyyg96MwQk6J7gAbiWnQ From: "Koeller, T." To: X-SecurE-Mail-Gateway: Version: 5.00.3.1 (smtpd: 6.53.8.7) Date: 20070205103557Z Subject: RE: [MIPS] Remove Basler Excite support Content-class: urn:content-classes:message Content-Type: text/plain; charset="iso-8859-2" Content-Transfer-Encoding: 8BIT Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13926 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Thomas.Koeller@baslerweb.com Precedence: bulk X-list: linux-mips Content-Length: 1575 Lines: 34 > From: linux-git-bounce@linux-mips.org > [mailto:linux-git-bounce@linux-mips.org] On Behalf Of > linux-mips@linux-mips.org > Sent: Sunday, February 04, 2007 9:39 PM > To: git-commits@linux-mips.org > Subject: [MIPS] Remove Basler Excite support Ralf, the last time I worked on it (which is three days ago, while working to make the excite nand flash driver ready for submission), it built and ran just fine, so I really wonder why you are removing it. I now notice that it has been made depending on BROKEN some time ago, which escaped my attention when it happened. The reason I did not encounter any build problems is that I always built the code with the yet-to-be-submitted drivers. The compilation error you get when building the excite platform is caused by a dependency upon the rm9k_serial driver, on which the platform depends for serial console support. I haven't yet managed to submit that driver, although I made several attempts. If serial console support were disabled, the code could trivially be fixed to compile without errors. Can you revert the removal? Thomas _______________________________ Thomas Köller, Software Developer Basler Vision Technologies An der Strusbek 60-62 22926 Ahrensburg Germany Tel. +49 (0) 4102 - 463 390 Fax +49 (0) 4102 - 463 390 mailto:thomas.koeller@baslerweb.com http://www.baslerweb.com Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) * John P. Jennings * Peter Krumhoff * Aufsichtsratsvorsitzender: Norbert Basler Basler AG * Amtsgericht Ahrensburg HRB 4090 * Ust-IdNr.: DE 135 098 121 * Steuer-Nr.: 30 292 04497 From vagabon.xyz@gmail.com Mon Feb 5 14:26:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:26:06 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.225]:40870 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037605AbXBEO0B (ORCPT ); Mon, 5 Feb 2007 14:26:01 +0000 Received: by hu-out-0506.google.com with SMTP id 27so1916916hub for ; Mon, 05 Feb 2007 06:25:29 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=RXEnKcHxO2We+ZQG/z6SYtwFz1eX9IgpdYd8Iz5gJ1k/jILaJFOQdIChPjg5SLmgYtHQBNpQfmAwPPHetjgnHBktYXLyNfxTemTRYIkMGZuPjiaCcb+PRr3Bg58Wn7JGeWsZiLU6Pm9HOJx2fPrnPPL+5Z+gSDGfj9NomhZJP3Q= Received: by 10.49.92.18 with SMTP id u18mr2276141nfl.1170685529193; Mon, 05 Feb 2007 06:25:29 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id p43sm27151715nfa.2007.02.05.06.25.27; Mon, 05 Feb 2007 06:25:28 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 361A423F76A; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 1/10] signals: reduce {setup,restore}_sigcontext sizes Date: Mon, 5 Feb 2007 15:24:19 +0100 Message-Id: <1170685469232-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13927 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 4007 Lines: 120 From: Franck Bui-Huu This trivial change reduces considerably code size of these 2 functions callers. For instance, here is the figures for arch/kernel/signal.o objects: text data bss dec hex filename 11972 0 0 11972 2ec4 arch/mips/kernel/signal.o~old 5380 0 0 5380 1504 arch/mips/kernel/signal.o~new Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal-common.h | 66 ++++++++++++-------------------------- 1 files changed, 21 insertions(+), 45 deletions(-) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index b1f09d5..bb3c631 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -13,22 +13,13 @@ static inline int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { int err = 0; + int i; err |= __put_user(regs->cp0_epc, &sc->sc_pc); -#define save_gp_reg(i) do { \ - err |= __put_user(regs->regs[i], &sc->sc_regs[i]); \ -} while(0) - __put_user(0, &sc->sc_regs[0]); save_gp_reg(1); save_gp_reg(2); - save_gp_reg(3); save_gp_reg(4); save_gp_reg(5); save_gp_reg(6); - save_gp_reg(7); save_gp_reg(8); save_gp_reg(9); save_gp_reg(10); - save_gp_reg(11); save_gp_reg(12); save_gp_reg(13); save_gp_reg(14); - save_gp_reg(15); save_gp_reg(16); save_gp_reg(17); save_gp_reg(18); - save_gp_reg(19); save_gp_reg(20); save_gp_reg(21); save_gp_reg(22); - save_gp_reg(23); save_gp_reg(24); save_gp_reg(25); save_gp_reg(26); - save_gp_reg(27); save_gp_reg(28); save_gp_reg(29); save_gp_reg(30); - save_gp_reg(31); -#undef save_gp_reg + err |= __put_user(0, &sc->sc_regs[0]); + for (i = 1; i < 32; i++) + err |= __put_user(regs->regs[i], &sc->sc_regs[i]); err |= __put_user(regs->hi, &sc->sc_mdhi); err |= __put_user(regs->lo, &sc->sc_mdlo); @@ -44,24 +35,21 @@ setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) err |= __put_user(!!used_math(), &sc->sc_used_math); - if (!used_math()) - goto out; - - /* - * Save FPU state to signal context. Signal handler will "inherit" - * current FPU state. - */ - preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); + if (used_math()) { + /* + * Save FPU state to signal context. Signal handler + * will "inherit" current FPU state. + */ + preempt_disable(); + + if (!is_fpu_owner()) { + own_fpu(); + restore_fp(current); + } + err |= save_fp_context(sc); + + preempt_enable(); } - err |= save_fp_context(sc); - - preempt_enable(); - -out: return err; } @@ -71,6 +59,7 @@ restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) unsigned int used_math; unsigned long treg; int err = 0; + int i; /* Always make any pending restarted system calls return -EINTR */ current_thread_info()->restart_block.fn = do_no_restart_syscall; @@ -88,21 +77,8 @@ restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); } -#define restore_gp_reg(i) do { \ - err |= __get_user(regs->regs[i], &sc->sc_regs[i]); \ -} while(0) - restore_gp_reg( 1); restore_gp_reg( 2); restore_gp_reg( 3); - restore_gp_reg( 4); restore_gp_reg( 5); restore_gp_reg( 6); - restore_gp_reg( 7); restore_gp_reg( 8); restore_gp_reg( 9); - restore_gp_reg(10); restore_gp_reg(11); restore_gp_reg(12); - restore_gp_reg(13); restore_gp_reg(14); restore_gp_reg(15); - restore_gp_reg(16); restore_gp_reg(17); restore_gp_reg(18); - restore_gp_reg(19); restore_gp_reg(20); restore_gp_reg(21); - restore_gp_reg(22); restore_gp_reg(23); restore_gp_reg(24); - restore_gp_reg(25); restore_gp_reg(26); restore_gp_reg(27); - restore_gp_reg(28); restore_gp_reg(29); restore_gp_reg(30); - restore_gp_reg(31); -#undef restore_gp_reg + for (i = 1; i < 32; i++) + err |= __get_user(regs->regs[i], &sc->sc_regs[i]); err |= __get_user(used_math, &sc->sc_used_math); conditional_used_math(used_math); -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:26:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:26:34 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.229]:2983 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037688AbXBEO0b (ORCPT ); Mon, 5 Feb 2007 14:26:31 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786004hug for ; Mon, 05 Feb 2007 06:25:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:from; b=NhIIXkekSdGkvXN9sFaAKTSyQ8Hn8yNHmBt0ii8l69PLFf4CE3D9bd4HnZt+Mhs7jdJ/95LnYmCf4QysXeoUHBLH774YPIi2yVo45YGrKqQrXllR09XUeXA3RgfAH5evchRtEo9M3879tlOmKxmhF/BjmVHqjmLwMkRat+/mhtA= Received: by 10.49.12.4 with SMTP id p4mr2275525nfi.1170685528890; Mon, 05 Feb 2007 06:25:28 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id k23sm27230643nfc.2007.02.05.06.25.27; Mon, 05 Feb 2007 06:25:28 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 28CDB23F76E; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: [PATCH 0/10] Clean up signal code [take #3] Date: Mon, 5 Feb 2007 15:24:18 +0100 Message-Id: <11706854683935-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13928 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 837 Lines: 31 Hi Ralf, Here is the third version of this patchset. I ran (on a 32-bits kernel _only_) all LTP signal testcases and they all passed. I haven't time to look at what these tests exactly do though. Changes from take #2: --------------------- - Do not use save_static_function() anymore - do not inline handle_signal() Changes from take #1: --------------------- - Fix ICACHE_REFILLS_WORKAROUND_WAR usages - Do not save/restore cp0_status register anymore - Check impact on performances Please, consider. Franck --- arch/mips/kernel/signal-common.h | 194 +++++----------------- arch/mips/kernel/signal.c | 231 +++++++++++++++++++------- arch/mips/kernel/signal32.c | 341 +++++++++++++++----------------------- arch/mips/kernel/signal_n32.c | 34 ++-- 4 files changed, 361 insertions(+), 439 deletions(-) From vagabon.xyz@gmail.com Mon Feb 5 14:26:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:27:04 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.233]:4775 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037707AbXBEO0b (ORCPT ); Mon, 5 Feb 2007 14:26:31 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786007hug for ; Mon, 05 Feb 2007 06:25:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=WgBzXmJyAlz/noQ1RLhoEJbPGJe6V968rlxz/USm3zXM9hzWmw0eUIp7GQy8CCysrDqt4u/ZqRI1+6eFzpRC1ImLK6IBjKo01Z6yJpY7sE9gv+DS2wGLYUwUaV/V6tkRhUvf/UkhECJQOAtVBjWnkg7UxXy2B2PXUPu2rQe7mCY= Received: by 10.49.10.3 with SMTP id n3mr2275208nfi.1170685529415; Mon, 05 Feb 2007 06:25:29 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id d2sm27144925nfe.2007.02.05.06.25.27; Mon, 05 Feb 2007 06:25:28 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 7375B23F76F; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 3/10] signal: clean up sigframe structure Date: Mon, 5 Feb 2007 15:24:21 +0100 Message-Id: <11706854693340-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13929 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 6613 Lines: 235 From: Franck Bui-Huu This patch makes 'struct sigframe' declaration avalaible for all signals code. It allows signal32 to not have its own declaration. This patch also removes all ICACHE_REFILLS_WORKAROUND_WAR tests in structure declaration and hopefully make them more readable. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal-common.h | 26 +++++++++++++++++ arch/mips/kernel/signal.c | 56 ++++++++++++++----------------------- arch/mips/kernel/signal32.c | 49 ++++++++++++++------------------- arch/mips/kernel/signal_n32.c | 19 +++++++++---- 4 files changed, 81 insertions(+), 69 deletions(-) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index 03d2b60..6700bde 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -12,6 +12,32 @@ #define __SIGNAL_COMMON_H /* + * Horribly complicated - with the bloody RM9000 workarounds enabled + * the signal trampolines is moving to the end of the structure so we can + * increase the alignment without breaking software compatibility. + */ +#if ICACHE_REFILLS_WORKAROUND_WAR == 0 + +struct sigframe { + u32 sf_ass[4]; /* argument save space for o32 */ + u32 sf_code[2]; /* signal trampoline */ + struct sigcontext sf_sc; + sigset_t sf_mask; +}; + +#else /* ICACHE_REFILLS_WORKAROUND_WAR */ + +struct sigframe { + u32 sf_ass[4]; /* argument save space for o32 */ + u32 sf_pad[2]; + struct sigcontext sf_sc; /* hw context */ + sigset_t sf_mask; + u32 sf_code[8] ____cacheline_aligned; /* signal trampoline */ +}; + +#endif /* !ICACHE_REFILLS_WORKAROUND_WAR */ + +/* * handle hardware context */ extern int setup_sigcontext(struct pt_regs *, struct sigcontext __user *); diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 7ec73f2..41033be 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -38,6 +38,27 @@ #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) +#if ICACHE_REFILLS_WORKAROUND_WAR == 0 + +struct rt_sigframe { + u32 rs_ass[4]; /* argument save space for o32 */ + u32 rs_code[2]; /* signal trampoline */ + struct siginfo rs_info; + struct ucontext rs_uc; +}; + +#else + +struct rt_sigframe { + u32 rs_ass[4]; /* argument save space for o32 */ + u32 rs_pad[2]; + struct siginfo rs_info; + struct ucontext rs_uc; + u32 rs_code[8] ____cacheline_aligned; /* signal trampoline */ +}; + +#endif + /* * Helper routines */ @@ -287,41 +308,6 @@ asmlinkage int sys_sigaltstack(nabi_no_regargs struct pt_regs regs) return do_sigaltstack(uss, uoss, usp); } -/* - * Horribly complicated - with the bloody RM9000 workarounds enabled - * the signal trampolines is moving to the end of the structure so we can - * increase the alignment without breaking software compatibility. - */ -#ifdef CONFIG_TRAD_SIGNALS -struct sigframe { - u32 sf_ass[4]; /* argument save space for o32 */ -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 sf_pad[2]; -#else - u32 sf_code[2]; /* signal trampoline */ -#endif - struct sigcontext sf_sc; - sigset_t sf_mask; -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 sf_code[8] ____cacheline_aligned; /* signal trampoline */ -#endif -}; -#endif - -struct rt_sigframe { - u32 rs_ass[4]; /* argument save space for o32 */ -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 rs_pad[2]; -#else - u32 rs_code[2]; /* signal trampoline */ -#endif - struct siginfo rs_info; - struct ucontext rs_uc; -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 rs_code[8] ____cacheline_aligned; /* signal trampoline */ -#endif -}; - #ifdef CONFIG_TRAD_SIGNALS save_static_function(sys_sigreturn); __attribute_used__ noinline static void diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index c86a5dd..e0a8553 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -139,6 +139,27 @@ struct ucontext32 { sigset_t32 uc_sigmask; /* mask last for extensibility */ }; +#if ICACHE_REFILLS_WORKAROUND_WAR == 0 + +struct rt_sigframe32 { + u32 rs_ass[4]; /* argument save space for o32 */ + u32 rs_code[2]; /* signal trampoline */ + compat_siginfo_t rs_info; + struct ucontext32 rs_uc; +}; + +#else /* ICACHE_REFILLS_WORKAROUND_WAR */ + +struct rt_sigframe32 { + u32 rs_ass[4]; /* argument save space for o32 */ + u32 rs_pad[2]; + compat_siginfo_t rs_info; + struct ucontext32 rs_uc; + u32 rs_code[8] __attribute__((aligned(32))); /* signal trampoline */ +}; + +#endif /* !ICACHE_REFILLS_WORKAROUND_WAR */ + extern void __put_sigset_unknown_nsig(void); extern void __get_sigset_unknown_nsig(void); @@ -383,34 +404,6 @@ static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user return err; } -struct sigframe { - u32 sf_ass[4]; /* argument save space for o32 */ -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 sf_pad[2]; -#else - u32 sf_code[2]; /* signal trampoline */ -#endif - struct sigcontext32 sf_sc; - sigset_t sf_mask; -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 sf_code[8] ____cacheline_aligned; /* signal trampoline */ -#endif -}; - -struct rt_sigframe32 { - u32 rs_ass[4]; /* argument save space for o32 */ -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 rs_pad[2]; -#else - u32 rs_code[2]; /* signal trampoline */ -#endif - compat_siginfo_t rs_info; - struct ucontext32 rs_uc; -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 rs_code[8] __attribute__((aligned(32))); /* signal trampoline */ -#endif -}; - int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from) { int err; diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index a67c185..f8e1539 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -66,20 +66,27 @@ struct ucontextn32 { sigset_t uc_sigmask; /* mask last for extensibility */ }; +#if ICACHE_REFILLS_WORKAROUND_WAR == 0 + struct rt_sigframe_n32 { u32 rs_ass[4]; /* argument save space for o32 */ -#if ICACHE_REFILLS_WORKAROUND_WAR - u32 rs_pad[2]; -#else u32 rs_code[2]; /* signal trampoline */ -#endif struct siginfo rs_info; struct ucontextn32 rs_uc; -#if ICACHE_REFILLS_WORKAROUND_WAR +}; + +#else /* ICACHE_REFILLS_WORKAROUND_WAR */ + +struct rt_sigframe_n32 { + u32 rs_ass[4]; /* argument save space for o32 */ + u32 rs_pad[2]; + struct siginfo rs_info; + struct ucontextn32 rs_uc; u32 rs_code[8] ____cacheline_aligned; /* signal trampoline */ -#endif }; +#endif /* !ICACHE_REFILLS_WORKAROUND_WAR */ + extern void sigset_from_compat (sigset_t *set, compat_sigset_t *compat); save_static_function(sysn32_rt_sigsuspend); -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:27:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:27:32 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.239]:6823 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037720AbXBEO0c (ORCPT ); Mon, 5 Feb 2007 14:26:32 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786009hug for ; Mon, 05 Feb 2007 06:25:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=ro2fPTVNIypzqD8326Wodu4ZSphcbtRZVCr8VPb/Ci8YGPqQCGEwgdjhIlPh7KJQB5/2Y9Q33/whGobnlyr62+dPe2pJJ5peaU9Usmr/ySiknpumOB+LYzavpxIBjHXqCXWxaQ8hIEZH+tLNY/hn9QJ1sTe9JmvqfjGdSXZ8lHM= Received: by 10.49.29.2 with SMTP id g2mr2279285nfj.1170685531335; Mon, 05 Feb 2007 06:25:31 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id l22sm27267860nfc.2007.02.05.06.25.30; Mon, 05 Feb 2007 06:25:30 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id AE13B23F774; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 5/10] signal: test return value of install_sigtramp() Date: Mon, 5 Feb 2007 15:24:23 +0100 Message-Id: <1170685469385-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13930 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1487 Lines: 41 From: Franck Bui-Huu Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal.c | 6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 41033be..5245135 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -184,7 +184,7 @@ int install_sigtramp(unsigned int __user *tramp, unsigned int syscall) */ err = __put_user(0x24020000 + syscall, tramp + 0); - err |= __put_user(0x0000000c , tramp + 1); + err |= __put_user(0x0000000c , tramp + 1); if (ICACHE_REFILLS_WORKAROUND_WAR) { err |= __put_user(0, tramp + 2); err |= __put_user(0, tramp + 3); @@ -400,7 +400,7 @@ int setup_frame(struct k_sigaction * ka, struct pt_regs *regs, if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame))) goto give_sigsegv; - install_sigtramp(frame->sf_code, __NR_sigreturn); + err |= install_sigtramp(frame->sf_code, __NR_sigreturn); err |= setup_sigcontext(regs, &frame->sf_sc); err |= __copy_to_user(&frame->sf_mask, set, sizeof(*set)); @@ -447,7 +447,7 @@ int setup_rt_frame(struct k_sigaction * ka, struct pt_regs *regs, if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame))) goto give_sigsegv; - install_sigtramp(frame->rs_code, __NR_rt_sigreturn); + err |= install_sigtramp(frame->rs_code, __NR_rt_sigreturn); /* Create siginfo. */ err |= copy_siginfo_to_user(&frame->rs_info, info); -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:27:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:28:01 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.233]:5799 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037715AbXBEO0c (ORCPT ); Mon, 5 Feb 2007 14:26:32 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786011hug for ; Mon, 05 Feb 2007 06:25:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=eHmTgSEj1bGZKd1GIgzN9ch5/pjaAxlF0kGm2Be9/44dCoOdG2d8sjakVtSE5RNEgJjGVmW/VpG4M8vhVFE/qYxrGQaW5YNMO3Fh+PHRLE14WSs/lkjb2Nngei6RbA0SWYOp28H2eK9oJpX97pD+4j1FmMjpNcpoFelZwgccc54= Received: by 10.48.48.18 with SMTP id v18mr2279253nfv.1170685531584; Mon, 05 Feb 2007 06:25:31 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id k23sm27230792nfc.2007.02.05.06.25.30; Mon, 05 Feb 2007 06:25:30 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id DCFC823F777; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 8/10] signal32: no need to save c0_status register in setup_sigcontext32() Date: Mon, 5 Feb 2007 15:24:26 +0100 Message-Id: <11706854691838-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13931 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 1026 Lines: 32 From: Franck Bui-Huu All the information in the MIPS c0_status register is priviledged. Nothing that would constitute part of the thread context. The one flag one could possibly argument about might be c0_status.fr but none of the ABIs or tools or application software can make use of it. So for consistency with restore_sigcontext32(), which does not restore c0_status register, this patch remove the saving part. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal32.c | 1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 5d102ef..0994d6e 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -170,7 +170,6 @@ static int setup_sigcontext32(struct pt_regs *regs, int i; err |= __put_user(regs->cp0_epc, &sc->sc_pc); - err |= __put_user(regs->cp0_status, &sc->sc_status); err |= __put_user(0, &sc->sc_regs[0]); for (i = 1; i < 32; i++) -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:28:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:28:28 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.233]:6055 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037721AbXBEO0d (ORCPT ); Mon, 5 Feb 2007 14:26:33 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786013hug for ; Mon, 05 Feb 2007 06:25:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=l1qbL9rW2DfVR7LsikKz519btKV1MDowhmL1VXxki1e44NYPUqHkvP+pxSAoGcRyohiPx046y+y8oISq0wJOPf2B1vivLPa0EnP7csdXFfklfzCBeosRyaOHWXmGQdXcBUEfe3XOumNkGpYrekAwBCrEq2EhheNGKd2GiYtEKAY= Received: by 10.48.204.7 with SMTP id b7mr2279060nfg.1170685531926; Mon, 05 Feb 2007 06:25:31 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id l21sm27165639nfc.2007.02.05.06.25.30; Mon, 05 Feb 2007 06:25:30 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id B307723F775; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 6/10] signal: factorize debug code Date: Mon, 5 Feb 2007 15:24:24 +0100 Message-Id: <11706854692156-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13932 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 4603 Lines: 144 From: Franck Bui-Huu Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal-common.h | 8 ++++++++ arch/mips/kernel/signal.c | 14 +++++--------- arch/mips/kernel/signal32.c | 16 ++++++---------- arch/mips/kernel/signal_n32.c | 7 ++----- 4 files changed, 21 insertions(+), 24 deletions(-) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index 6700bde..9a8abd6 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -11,6 +11,14 @@ #ifndef __SIGNAL_COMMON_H #define __SIGNAL_COMMON_H +/* #define DEBUG_SIG */ + +#ifdef DEBUG_SIG +# define DEBUGP(fmt, args...) printk("%s: " fmt, __FUNCTION__ , ##args) +#else +# define DEBUGP(fmt, args...) +#endif + /* * Horribly complicated - with the bloody RM9000 workarounds enabled * the signal trampolines is moving to the end of the structure so we can diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 5245135..d3f6b0a 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -34,8 +34,6 @@ #include "signal-common.h" -#define DEBUG_SIG 0 - #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) #if ICACHE_REFILLS_WORKAROUND_WAR == 0 @@ -424,11 +422,10 @@ int setup_frame(struct k_sigaction * ka, struct pt_regs *regs, regs->regs[31] = (unsigned long) frame->sf_code; regs->cp0_epc = regs->regs[25] = (unsigned long) ka->sa.sa_handler; -#if DEBUG_SIG - printk("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%p\n", + DEBUGP("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%lx\n", current->comm, current->pid, - frame, regs->cp0_epc, frame->regs[31]); -#endif + frame, regs->cp0_epc, regs->regs[31]); + return 0; give_sigsegv: @@ -484,11 +481,10 @@ int setup_rt_frame(struct k_sigaction * ka, struct pt_regs *regs, regs->regs[31] = (unsigned long) frame->rs_code; regs->cp0_epc = regs->regs[25] = (unsigned long) ka->sa.sa_handler; -#if DEBUG_SIG - printk("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%p\n", + DEBUGP("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%lx\n", current->comm, current->pid, frame, regs->cp0_epc, regs->regs[31]); -#endif + return 0; give_sigsegv: diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 5934f33..1a99a57 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -104,8 +104,6 @@ typedef struct compat_siginfo { #define __NR_O32_rt_sigreturn 4193 #define __NR_O32_restart_syscall 4253 -#define DEBUG_SIG 0 - #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) /* 32-bit compatibility types */ @@ -640,11 +638,10 @@ int setup_frame_32(struct k_sigaction * ka, struct pt_regs *regs, regs->regs[31] = (unsigned long) frame->sf_code; regs->cp0_epc = regs->regs[25] = (unsigned long) ka->sa.sa_handler; -#if DEBUG_SIG - printk("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%p\n", + DEBUGP("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%lx\n", current->comm, current->pid, - frame, regs->cp0_epc, frame->sf_code); -#endif + frame, regs->cp0_epc, regs->regs[31]); + return 0; give_sigsegv: @@ -701,11 +698,10 @@ int setup_rt_frame_32(struct k_sigaction * ka, struct pt_regs *regs, regs->regs[31] = (unsigned long) frame->rs_code; regs->cp0_epc = regs->regs[25] = (unsigned long) ka->sa.sa_handler; -#if DEBUG_SIG - printk("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%p\n", + DEBUGP("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%lx\n", current->comm, current->pid, - frame, regs->cp0_epc, frame->rs_code); -#endif + frame, regs->cp0_epc, regs->regs[31]); + return 0; give_sigsegv: diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index f8e1539..a6c1e67 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -47,8 +47,6 @@ #define __NR_N32_rt_sigreturn 6211 #define __NR_N32_restart_syscall 6214 -#define DEBUG_SIG 0 - #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) /* IRIX compatible stack_t */ @@ -221,11 +219,10 @@ int setup_rt_frame_n32(struct k_sigaction * ka, regs->regs[31] = (unsigned long) frame->rs_code; regs->cp0_epc = regs->regs[25] = (unsigned long) ka->sa.sa_handler; -#if DEBUG_SIG - printk("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%p\n", + DEBUGP("SIG deliver (%s:%d): sp=0x%p pc=0x%lx ra=0x%lx\n", current->comm, current->pid, frame, regs->cp0_epc, regs->regs[31]); -#endif + return 0; give_sigsegv: -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:28:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:28:57 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.224]:7591 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037739AbXBEO0j (ORCPT ); Mon, 5 Feb 2007 14:26:39 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786023hug for ; Mon, 05 Feb 2007 06:25:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=dT14G2fg/ninGA1fzOiLT9YO0s3dtJt2LGm/2INkEX20aUdnDgXHDbEILXcLckNlVHgILynuxO1ssbeUS35QiPz5O1E/Ais5pGZCWvwEbeTuucuw+lBcGDR2DOuYZE+tS8pvfar5z6sThHcE0Xe1req8c2Xbsgrjp7WUJC85iFo= Received: by 10.49.20.5 with SMTP id x5mr2277402nfi.1170685529901; Mon, 05 Feb 2007 06:25:29 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id k9sm27259698nfc.2007.02.05.06.25.28; Mon, 05 Feb 2007 06:25:28 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 91FDA23F772; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 4/10] signal32: remove code duplication Date: Mon, 5 Feb 2007 15:24:22 +0100 Message-Id: <1170685469836-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13933 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 3018 Lines: 97 From: Franck Bui-Huu There's no point for signal32.c to redefine get_sigframe(). It should use the one define in signal.c instead. The same stands for install_sigtramp(). Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal32.c | 50 +++--------------------------------------- 1 files changed, 4 insertions(+), 46 deletions(-) diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index e0a8553..5934f33 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -33,6 +33,8 @@ #include #include +#include "signal-common.h" + #define SI_PAD_SIZE32 ((SI_MAX_SIZE/sizeof(int)) - 3) typedef struct compat_siginfo { @@ -604,32 +606,6 @@ out: return err; } -/* - * Determine which stack to use.. - */ -static inline void __user *get_sigframe(struct k_sigaction *ka, - struct pt_regs *regs, - size_t frame_size) -{ - unsigned long sp; - - /* Default to using normal stack */ - sp = regs->regs[29]; - - /* - * FPU emulator may have it's own trampoline active just - * above the user stack, 16-bytes before the next lowest - * 16 byte boundary. Try to avoid trashing it. - */ - sp -= 32; - - /* This is the X/Open sanctioned signal stack switching. */ - if ((ka->sa.sa_flags & SA_ONSTACK) && (sas_ss_flags (sp) == 0)) - sp = current->sas_ss_sp + current->sas_ss_size; - - return (void __user *)((sp - frame_size) & ALMASK); -} - int setup_frame_32(struct k_sigaction * ka, struct pt_regs *regs, int signr, sigset_t *set) { @@ -640,15 +616,7 @@ int setup_frame_32(struct k_sigaction * ka, struct pt_regs *regs, if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame))) goto give_sigsegv; - /* - * Set up the return code ... - * - * li v0, __NR_O32_sigreturn - * syscall - */ - err |= __put_user(0x24020000 + __NR_O32_sigreturn, frame->sf_code + 0); - err |= __put_user(0x0000000c , frame->sf_code + 1); - flush_cache_sigtramp((unsigned long) frame->sf_code); + err |= install_sigtramp(frame->sf_code, __NR_O32_sigreturn); err |= setup_sigcontext32(regs, &frame->sf_sc); err |= __copy_to_user(&frame->sf_mask, set, sizeof(*set)); @@ -695,17 +663,7 @@ int setup_rt_frame_32(struct k_sigaction * ka, struct pt_regs *regs, if (!access_ok(VERIFY_WRITE, frame, sizeof (*frame))) goto give_sigsegv; - /* Set up to return from userspace. If provided, use a stub already - in userspace. */ - /* - * Set up the return code ... - * - * li v0, __NR_O32_rt_sigreturn - * syscall - */ - err |= __put_user(0x24020000 + __NR_O32_rt_sigreturn, frame->rs_code + 0); - err |= __put_user(0x0000000c , frame->rs_code + 1); - flush_cache_sigtramp((unsigned long) frame->rs_code); + err |= install_sigtramp(frame->rs_code, __NR_O32_rt_sigreturn); /* Convert (siginfo_t -> compat_siginfo_t) and copy to user. */ err |= copy_siginfo_to_user32(&frame->rs_info, info); -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:29:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:29:26 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.225]:7335 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037737AbXBEO0j (ORCPT ); Mon, 5 Feb 2007 14:26:39 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786024hug for ; Mon, 05 Feb 2007 06:25:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=TUW1cLDbNTiVEj00yc+QUVLH2Z0Qo1hrMBXyPUI3Omn1MZvprjb5QFcXc2mv4c1OBJVyVC7SUdfgD4H02g5c1j13d4oO2yTc4pfDxPiCi05+++sMf8SuXtEjMCRoCbPitFOBZYBq1ChJN4VpabCRXRE/CaM9o24EdZPGtdSpUkc= Received: by 10.48.240.10 with SMTP id n10mr2278484nfh.1170685533409; Mon, 05 Feb 2007 06:25:33 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id p43sm27151883nfa.2007.02.05.06.25.30; Mon, 05 Feb 2007 06:25:32 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id D724C23F776; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 7/10] signal32: reduce {setup,restore}_sigcontext32 sizes Date: Mon, 5 Feb 2007 15:24:25 +0100 Message-Id: <11706854691291-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13934 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 7215 Lines: 249 From: Franck Bui-Huu This trivial changes should decrease a lot the size of these 2 functions. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal32.c | 211 ++++++++++++++++++++----------------------- 1 files changed, 97 insertions(+), 114 deletions(-) diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 1a99a57..5d102ef 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -160,6 +160,103 @@ struct rt_sigframe32 { #endif /* !ICACHE_REFILLS_WORKAROUND_WAR */ +/* + * sigcontext handlers + */ +static int setup_sigcontext32(struct pt_regs *regs, + struct sigcontext32 __user *sc) +{ + int err = 0; + int i; + + err |= __put_user(regs->cp0_epc, &sc->sc_pc); + err |= __put_user(regs->cp0_status, &sc->sc_status); + + err |= __put_user(0, &sc->sc_regs[0]); + for (i = 1; i < 32; i++) + err |= __put_user(regs->regs[i], &sc->sc_regs[i]); + + err |= __put_user(regs->hi, &sc->sc_mdhi); + err |= __put_user(regs->lo, &sc->sc_mdlo); + if (cpu_has_dsp) { + err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp); + err |= __put_user(mfhi1(), &sc->sc_hi1); + err |= __put_user(mflo1(), &sc->sc_lo1); + err |= __put_user(mfhi2(), &sc->sc_hi2); + err |= __put_user(mflo2(), &sc->sc_lo2); + err |= __put_user(mfhi3(), &sc->sc_hi3); + err |= __put_user(mflo3(), &sc->sc_lo3); + } + + err |= __put_user(!!used_math(), &sc->sc_used_math); + + if (used_math()) { + /* + * Save FPU state to signal context. Signal handler + * will "inherit" current FPU state. + */ + preempt_disable(); + + if (!is_fpu_owner()) { + own_fpu(); + restore_fp(current); + } + err |= save_fp_context32(sc); + + preempt_enable(); + } + return err; +} + +static int restore_sigcontext32(struct pt_regs *regs, + struct sigcontext32 __user *sc) +{ + u32 used_math; + int err = 0; + s32 treg; + int i; + + /* Always make any pending restarted system calls return -EINTR */ + current_thread_info()->restart_block.fn = do_no_restart_syscall; + + err |= __get_user(regs->cp0_epc, &sc->sc_pc); + err |= __get_user(regs->hi, &sc->sc_mdhi); + err |= __get_user(regs->lo, &sc->sc_mdlo); + if (cpu_has_dsp) { + err |= __get_user(treg, &sc->sc_hi1); mthi1(treg); + err |= __get_user(treg, &sc->sc_lo1); mtlo1(treg); + err |= __get_user(treg, &sc->sc_hi2); mthi2(treg); + err |= __get_user(treg, &sc->sc_lo2); mtlo2(treg); + err |= __get_user(treg, &sc->sc_hi3); mthi3(treg); + err |= __get_user(treg, &sc->sc_lo3); mtlo3(treg); + err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); + } + + for (i = 1; i < 32; i++) + err |= __get_user(regs->regs[i], &sc->sc_regs[i]); + + err |= __get_user(used_math, &sc->sc_used_math); + conditional_used_math(used_math); + + preempt_disable(); + + if (used_math()) { + /* restore fpu context if we have used it before */ + own_fpu(); + err |= restore_fp_context32(sc); + } else { + /* signal handler may have used FPU. Give it up. */ + lose_fpu(); + } + + preempt_enable(); + + return err; +} + +/* + * + */ extern void __put_sigset_unknown_nsig(void); extern void __get_sigset_unknown_nsig(void); @@ -347,63 +444,6 @@ asmlinkage int sys32_sigaltstack(nabi_no_regargs struct pt_regs regs) return ret; } -static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) -{ - u32 used_math; - int err = 0; - s32 treg; - - /* Always make any pending restarted system calls return -EINTR */ - current_thread_info()->restart_block.fn = do_no_restart_syscall; - - err |= __get_user(regs->cp0_epc, &sc->sc_pc); - err |= __get_user(regs->hi, &sc->sc_mdhi); - err |= __get_user(regs->lo, &sc->sc_mdlo); - if (cpu_has_dsp) { - err |= __get_user(treg, &sc->sc_hi1); mthi1(treg); - err |= __get_user(treg, &sc->sc_lo1); mtlo1(treg); - err |= __get_user(treg, &sc->sc_hi2); mthi2(treg); - err |= __get_user(treg, &sc->sc_lo2); mtlo2(treg); - err |= __get_user(treg, &sc->sc_hi3); mthi3(treg); - err |= __get_user(treg, &sc->sc_lo3); mtlo3(treg); - err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); - } - -#define restore_gp_reg(i) do { \ - err |= __get_user(regs->regs[i], &sc->sc_regs[i]); \ -} while(0) - restore_gp_reg( 1); restore_gp_reg( 2); restore_gp_reg( 3); - restore_gp_reg( 4); restore_gp_reg( 5); restore_gp_reg( 6); - restore_gp_reg( 7); restore_gp_reg( 8); restore_gp_reg( 9); - restore_gp_reg(10); restore_gp_reg(11); restore_gp_reg(12); - restore_gp_reg(13); restore_gp_reg(14); restore_gp_reg(15); - restore_gp_reg(16); restore_gp_reg(17); restore_gp_reg(18); - restore_gp_reg(19); restore_gp_reg(20); restore_gp_reg(21); - restore_gp_reg(22); restore_gp_reg(23); restore_gp_reg(24); - restore_gp_reg(25); restore_gp_reg(26); restore_gp_reg(27); - restore_gp_reg(28); restore_gp_reg(29); restore_gp_reg(30); - restore_gp_reg(31); -#undef restore_gp_reg - - err |= __get_user(used_math, &sc->sc_used_math); - conditional_used_math(used_math); - - preempt_disable(); - - if (used_math()) { - /* restore fpu context if we have used it before */ - own_fpu(); - err |= restore_fp_context32(sc); - } else { - /* signal handler may have used FPU. Give it up. */ - lose_fpu(); - } - - preempt_enable(); - - return err; -} - int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from) { int err; @@ -547,63 +587,6 @@ badframe: force_sig(SIGSEGV, current); } -static inline int setup_sigcontext32(struct pt_regs *regs, - struct sigcontext32 __user *sc) -{ - int err = 0; - - err |= __put_user(regs->cp0_epc, &sc->sc_pc); - err |= __put_user(regs->cp0_status, &sc->sc_status); - -#define save_gp_reg(i) { \ - err |= __put_user(regs->regs[i], &sc->sc_regs[i]); \ -} while(0) - __put_user(0, &sc->sc_regs[0]); save_gp_reg(1); save_gp_reg(2); - save_gp_reg(3); save_gp_reg(4); save_gp_reg(5); save_gp_reg(6); - save_gp_reg(7); save_gp_reg(8); save_gp_reg(9); save_gp_reg(10); - save_gp_reg(11); save_gp_reg(12); save_gp_reg(13); save_gp_reg(14); - save_gp_reg(15); save_gp_reg(16); save_gp_reg(17); save_gp_reg(18); - save_gp_reg(19); save_gp_reg(20); save_gp_reg(21); save_gp_reg(22); - save_gp_reg(23); save_gp_reg(24); save_gp_reg(25); save_gp_reg(26); - save_gp_reg(27); save_gp_reg(28); save_gp_reg(29); save_gp_reg(30); - save_gp_reg(31); -#undef save_gp_reg - - err |= __put_user(regs->hi, &sc->sc_mdhi); - err |= __put_user(regs->lo, &sc->sc_mdlo); - if (cpu_has_dsp) { - err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp); - err |= __put_user(mfhi1(), &sc->sc_hi1); - err |= __put_user(mflo1(), &sc->sc_lo1); - err |= __put_user(mfhi2(), &sc->sc_hi2); - err |= __put_user(mflo2(), &sc->sc_lo2); - err |= __put_user(mfhi3(), &sc->sc_hi3); - err |= __put_user(mflo3(), &sc->sc_lo3); - } - - err |= __put_user(!!used_math(), &sc->sc_used_math); - - if (!used_math()) - goto out; - - /* - * Save FPU state to signal context. Signal handler will "inherit" - * current FPU state. - */ - preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); - } - err |= save_fp_context32(sc); - - preempt_enable(); - -out: - return err; -} - int setup_frame_32(struct k_sigaction * ka, struct pt_regs *regs, int signr, sigset_t *set) { -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:29:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:29:53 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.224]:8615 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037605AbXBEO0k (ORCPT ); Mon, 5 Feb 2007 14:26:40 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786025hug for ; Mon, 05 Feb 2007 06:25:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=jIq2TAMsdfHmM1lpYmgWk258HVDsXNMXRjEQUg1yV3w2d7j0gSi9q/AGuRG/IL5JJv5Dc+W6fO+eu8pNGzDrK1LL9ZNR1qRTi9xMKnB/DidobRytdyJS/Su9LLp1OBbcQiGPYx7bhmWGrsPiA894JN6U3qyQypnUh0H9egg0VIU= Received: by 10.49.43.2 with SMTP id v2mr2275053nfj.1170685533163; Mon, 05 Feb 2007 06:25:33 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id k9sm27259806nfc.2007.02.05.06.25.30; Mon, 05 Feb 2007 06:25:32 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 0C4B623F778; Mon, 5 Feb 2007 15:24:30 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 9/10] signal: do not use save_static_function() anymore Date: Mon, 5 Feb 2007 15:24:27 +0100 Message-Id: <11706854703880-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13935 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 4893 Lines: 143 From: Franck Bui-Huu This macro was used to save static registers before calling sys_sigsuspend() and sys_sigreturn(). For the sys_sigreturn() case, there's no point to save them since they have been already saved by setup_sigcontext() before calling the signal handler. For the sys_sigsuspend() case, I don't see any reasons... Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal.c | 16 ++++------------ arch/mips/kernel/signal32.c | 16 ++++------------ arch/mips/kernel/signal_n32.c | 8 ++------ 3 files changed, 10 insertions(+), 30 deletions(-) diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index d3f6b0a..32d4022 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -201,9 +201,7 @@ int install_sigtramp(unsigned int __user *tramp, unsigned int syscall) */ #ifdef CONFIG_TRAD_SIGNALS -save_static_function(sys_sigsuspend); -__attribute_used__ noinline static int -_sys_sigsuspend(nabi_no_regargs struct pt_regs regs) +asmlinkage int sys_sigsuspend(nabi_no_regargs struct pt_regs regs) { sigset_t newset; sigset_t __user *uset; @@ -226,9 +224,7 @@ _sys_sigsuspend(nabi_no_regargs struct pt_regs regs) } #endif -save_static_function(sys_rt_sigsuspend); -__attribute_used__ noinline static int -_sys_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) +asmlinkage int sys_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) { sigset_t newset; sigset_t __user *unewset; @@ -307,9 +303,7 @@ asmlinkage int sys_sigaltstack(nabi_no_regargs struct pt_regs regs) } #ifdef CONFIG_TRAD_SIGNALS -save_static_function(sys_sigreturn); -__attribute_used__ noinline static void -_sys_sigreturn(nabi_no_regargs struct pt_regs regs) +asmlinkage void sys_sigreturn(nabi_no_regargs struct pt_regs regs) { struct sigframe __user *frame; sigset_t blocked; @@ -344,9 +338,7 @@ badframe: } #endif /* CONFIG_TRAD_SIGNALS */ -save_static_function(sys_rt_sigreturn); -__attribute_used__ noinline static void -_sys_rt_sigreturn(nabi_no_regargs struct pt_regs regs) +asmlinkage void sys_rt_sigreturn(nabi_no_regargs struct pt_regs regs) { struct rt_sigframe __user *frame; sigset_t set; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 0994d6e..183fc7e 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -308,9 +308,7 @@ static inline int get_sigset(sigset_t *kbuf, const compat_sigset_t __user *ubuf) * Atomically swap in the new signal mask, and wait for a signal. */ -save_static_function(sys32_sigsuspend); -__attribute_used__ noinline static int -_sys32_sigsuspend(nabi_no_regargs struct pt_regs regs) +asmlinkage int sys32_sigsuspend(nabi_no_regargs struct pt_regs regs) { compat_sigset_t __user *uset; sigset_t newset; @@ -332,9 +330,7 @@ _sys32_sigsuspend(nabi_no_regargs struct pt_regs regs) return -ERESTARTNOHAND; } -save_static_function(sys32_rt_sigsuspend); -__attribute_used__ noinline static int -_sys32_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) +asmlinkage int sys32_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) { compat_sigset_t __user *uset; sigset_t newset; @@ -495,9 +491,7 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t *from) return err; } -save_static_function(sys32_sigreturn); -__attribute_used__ noinline static void -_sys32_sigreturn(nabi_no_regargs struct pt_regs regs) +asmlinkage void sys32_sigreturn(nabi_no_regargs struct pt_regs regs) { struct sigframe __user *frame; sigset_t blocked; @@ -531,9 +525,7 @@ badframe: force_sig(SIGSEGV, current); } -save_static_function(sys32_rt_sigreturn); -__attribute_used__ noinline static void -_sys32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) +asmlinkage void sys32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) { struct rt_sigframe32 __user *frame; mm_segment_t old_fs; diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index a6c1e67..35bfbc7 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -87,9 +87,7 @@ struct rt_sigframe_n32 { extern void sigset_from_compat (sigset_t *set, compat_sigset_t *compat); -save_static_function(sysn32_rt_sigsuspend); -__attribute_used__ noinline static int -_sysn32_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) +asmlinkage int sysn32_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) { compat_sigset_t __user *unewset; compat_sigset_t uset; @@ -119,9 +117,7 @@ _sysn32_rt_sigsuspend(nabi_no_regargs struct pt_regs regs) return -ERESTARTNOHAND; } -save_static_function(sysn32_rt_sigreturn); -__attribute_used__ noinline static void -_sysn32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) +asmlinkage void sysn32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) { struct rt_sigframe_n32 __user *frame; sigset_t set; -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Mon Feb 5 14:30:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:30:22 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.236]:12199 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037742AbXBEO0m (ORCPT ); Mon, 5 Feb 2007 14:26:42 +0000 Received: by hu-out-0506.google.com with SMTP id 22so786032hug for ; Mon, 05 Feb 2007 06:25:38 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=uOnCGj6UufXct8AS/JvnhOmK6RA4pkUN9MfhgGPp9tv5fY8uHfwdT/cAYIHywwTNl4JbeFRRWP/X1ffwpf1Edb9VYMWKyCAdg3AiewjtqeM8+TrYFgAbMdn7KcOG7Xl8AekBUC4pToIG48uaB8wjizTrfPz249o1SUlffUlABPo= Received: by 10.49.36.6 with SMTP id o6mr2274959nfj.1170685532207; Mon, 05 Feb 2007 06:25:32 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id a23sm27251211nfc.2007.02.05.06.25.30; Mon, 05 Feb 2007 06:25:31 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 302BE23F779; Mon, 5 Feb 2007 15:24:30 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 10/10] signal: do not inline handle_signal() Date: Mon, 5 Feb 2007 15:24:28 +0100 Message-Id: <11706854701492-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13936 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 632 Lines: 23 From: Franck Bui-Huu Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 32d4022..229276a 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -484,7 +484,7 @@ give_sigsegv: return -EFAULT; } -static inline int handle_signal(unsigned long sig, siginfo_t *info, +static int handle_signal(unsigned long sig, siginfo_t *info, struct k_sigaction *ka, sigset_t *oldset, struct pt_regs *regs) { int ret; -- 1.4.4.3.ge6d4 From sergio@amilda.org Mon Feb 5 14:35:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:35:26 +0000 (GMT) Received: from www.pc-net.at ([193.238.157.29]:35547 "EHLO MrWeb01.pc-net.at") by ftp.linux-mips.org with ESMTP id S20037701AbXBEOfW (ORCPT ); Mon, 5 Feb 2007 14:35:22 +0000 Received: from localhost (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 4D825215ECD for ; Mon, 5 Feb 2007 15:34:45 +0100 (CET) Received: from MrWeb01.pc-net.at ([127.0.0.1]) by localhost (MrWeb01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 06389-06 for ; Mon, 5 Feb 2007 15:34:43 +0100 (CET) Received: from www.amilda.org (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id C8C5A215ECA for ; Mon, 5 Feb 2007 15:34:32 +0100 (CET) Received: from 201.240.249.124 (SquirrelMail authenticated user amilda0001) by www.amilda.org with HTTP; Mon, 5 Feb 2007 09:34:43 -0500 (PET) Message-ID: <24895.201.240.249.124.1170686083.squirrel@www.amilda.org> In-Reply-To: <45C45DDA.1000805@wp.pl> References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> <45C3BB23.2070309@wp.pl> <50812.201.230.45.190.1170482268.squirrel@www.amilda.org> <45C45DDA.1000805@wp.pl> Date: Mon, 5 Feb 2007 09:34:43 -0500 (PET) Subject: Re: Advice needed. From: "Sergio Aguayo" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.6-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pc-net.at Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13937 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sergio@amilda.org Precedence: bulk X-list: linux-mips Content-Length: 1045 Lines: 39 > > >>Are you talking about the configuration structure? If so, it varies >>between model to model. AMiLDA itself uses a totally different >>configuration which may very from version to version. >> >> >> > Yes. The configuration structure is difficult to understand (even if you have the C header containing the struct) because of many conditional compiling macros (if this model, and not that one or this but not the other, etc). Just use the "flash" program. > >>That means that webs encountered an error starting up. Usually it is due >>to another webs instance already running or another process that has port >>80 opened. >> >> > That is not the case, sure. > When webs does that, it means that it encountered an error during startup. If i remember correctly, webs does the following during startup: - Allocate some memory for its own use. - Figure out the document root. - Register asp and cgi functions. - Bind to port 80 (or whatever it is told to use) If any of these fail, then you will experience that simpton. Sergio From vagabon.xyz@gmail.com Mon Feb 5 14:55:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 14:55:55 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.238]:4290 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037726AbXBEOzt (ORCPT ); Mon, 5 Feb 2007 14:55:49 +0000 Received: by hu-out-0506.google.com with SMTP id 22so789668hug for ; Mon, 05 Feb 2007 06:54:45 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=HXiSh2ca8LnxLl7oy9HNs2HNreDHVvmX8joj7fO9d1xQ7ieHaY/mJzxdNCdYjCLmOHj2+TrMygo2ljzTNjY5NPAHiunPrUFHK13q2wSWmpdeNytKebJjLX34MGc0sP7fBK2yBa/LV41odEizcbfGWgIwvijeTvqSocND9ZNaI5Y= Received: by 10.82.152.16 with SMTP id z16mr2002254bud.1170687284178; Mon, 05 Feb 2007 06:54:44 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id p72sm27309769nfc.2007.02.05.06.54.42; Mon, 05 Feb 2007 06:54:43 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 544C623F770; Mon, 5 Feb 2007 15:24:29 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, Franck Bui-Huu Subject: [PATCH 2/10] signal: do not inline functions in signal-common.h Date: Mon, 5 Feb 2007 15:24:20 +0100 Message-Id: <11706854691613-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13938 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Content-Length: 9146 Lines: 330 From: Franck Bui-Huu These functions are quite big and there are no points to make them inlined. So this patch moves the functions implementation in signal.c and make them available for others source files which need them. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal-common.h | 150 ++++---------------------------------- arch/mips/kernel/signal.c | 139 +++++++++++++++++++++++++++++++++++ 2 files changed, 153 insertions(+), 136 deletions(-) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index bb3c631..03d2b60 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -8,145 +8,23 @@ * Copyright (C) 1999, 2000 Silicon Graphics, Inc. */ +#ifndef __SIGNAL_COMMON_H +#define __SIGNAL_COMMON_H -static inline int -setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) -{ - int err = 0; - int i; - - err |= __put_user(regs->cp0_epc, &sc->sc_pc); - - err |= __put_user(0, &sc->sc_regs[0]); - for (i = 1; i < 32; i++) - err |= __put_user(regs->regs[i], &sc->sc_regs[i]); - - err |= __put_user(regs->hi, &sc->sc_mdhi); - err |= __put_user(regs->lo, &sc->sc_mdlo); - if (cpu_has_dsp) { - err |= __put_user(mfhi1(), &sc->sc_hi1); - err |= __put_user(mflo1(), &sc->sc_lo1); - err |= __put_user(mfhi2(), &sc->sc_hi2); - err |= __put_user(mflo2(), &sc->sc_lo2); - err |= __put_user(mfhi3(), &sc->sc_hi3); - err |= __put_user(mflo3(), &sc->sc_lo3); - err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp); - } - - err |= __put_user(!!used_math(), &sc->sc_used_math); - - if (used_math()) { - /* - * Save FPU state to signal context. Signal handler - * will "inherit" current FPU state. - */ - preempt_disable(); - - if (!is_fpu_owner()) { - own_fpu(); - restore_fp(current); - } - err |= save_fp_context(sc); - - preempt_enable(); - } - return err; -} - -static inline int -restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) -{ - unsigned int used_math; - unsigned long treg; - int err = 0; - int i; - - /* Always make any pending restarted system calls return -EINTR */ - current_thread_info()->restart_block.fn = do_no_restart_syscall; - - err |= __get_user(regs->cp0_epc, &sc->sc_pc); - err |= __get_user(regs->hi, &sc->sc_mdhi); - err |= __get_user(regs->lo, &sc->sc_mdlo); - if (cpu_has_dsp) { - err |= __get_user(treg, &sc->sc_hi1); mthi1(treg); - err |= __get_user(treg, &sc->sc_lo1); mtlo1(treg); - err |= __get_user(treg, &sc->sc_hi2); mthi2(treg); - err |= __get_user(treg, &sc->sc_lo2); mtlo2(treg); - err |= __get_user(treg, &sc->sc_hi3); mthi3(treg); - err |= __get_user(treg, &sc->sc_lo3); mtlo3(treg); - err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); - } - - for (i = 1; i < 32; i++) - err |= __get_user(regs->regs[i], &sc->sc_regs[i]); - - err |= __get_user(used_math, &sc->sc_used_math); - conditional_used_math(used_math); - - preempt_disable(); - - if (used_math()) { - /* restore fpu context if we have used it before */ - own_fpu(); - err |= restore_fp_context(sc); - } else { - /* signal handler may have used FPU. Give it up. */ - lose_fpu(); - } - - preempt_enable(); - - return err; -} +/* + * handle hardware context + */ +extern int setup_sigcontext(struct pt_regs *, struct sigcontext __user *); +extern int restore_sigcontext(struct pt_regs *, struct sigcontext __user *); /* * Determine which stack to use.. */ -static inline void __user * -get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, size_t frame_size) -{ - unsigned long sp; - - /* Default to using normal stack */ - sp = regs->regs[29]; - - /* - * FPU emulator may have it's own trampoline active just - * above the user stack, 16-bytes before the next lowest - * 16 byte boundary. Try to avoid trashing it. - */ - sp -= 32; - - /* This is the X/Open sanctioned signal stack switching. */ - if ((ka->sa.sa_flags & SA_ONSTACK) && (sas_ss_flags (sp) == 0)) - sp = current->sas_ss_sp + current->sas_ss_size; - - return (void __user *)((sp - frame_size) & (ICACHE_REFILLS_WORKAROUND_WAR ? ~(cpu_icache_line_size()-1) : ALMASK)); -} - -static inline int install_sigtramp(unsigned int __user *tramp, - unsigned int syscall) -{ - int err; - - /* - * Set up the return code ... - * - * li v0, __NR__foo_sigreturn - * syscall - */ - - err = __put_user(0x24020000 + syscall, tramp + 0); - err |= __put_user(0x0000000c , tramp + 1); - if (ICACHE_REFILLS_WORKAROUND_WAR) { - err |= __put_user(0, tramp + 2); - err |= __put_user(0, tramp + 3); - err |= __put_user(0, tramp + 4); - err |= __put_user(0, tramp + 5); - err |= __put_user(0, tramp + 6); - err |= __put_user(0, tramp + 7); - } - flush_cache_sigtramp((unsigned long) tramp); +extern void __user *get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, + size_t frame_size); +/* + * install trampoline code to get back from the sig handler + */ +extern int install_sigtramp(unsigned int __user *tramp, unsigned int syscall); - return err; -} +#endif /* __SIGNAL_COMMON_H */ diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index b9d358e..7ec73f2 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -39,6 +39,145 @@ #define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) /* + * Helper routines + */ +int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) +{ + int err = 0; + int i; + + err |= __put_user(regs->cp0_epc, &sc->sc_pc); + + err |= __put_user(0, &sc->sc_regs[0]); + for (i = 1; i < 32; i++) + err |= __put_user(regs->regs[i], &sc->sc_regs[i]); + + err |= __put_user(regs->hi, &sc->sc_mdhi); + err |= __put_user(regs->lo, &sc->sc_mdlo); + if (cpu_has_dsp) { + err |= __put_user(mfhi1(), &sc->sc_hi1); + err |= __put_user(mflo1(), &sc->sc_lo1); + err |= __put_user(mfhi2(), &sc->sc_hi2); + err |= __put_user(mflo2(), &sc->sc_lo2); + err |= __put_user(mfhi3(), &sc->sc_hi3); + err |= __put_user(mflo3(), &sc->sc_lo3); + err |= __put_user(rddsp(DSP_MASK), &sc->sc_dsp); + } + + err |= __put_user(!!used_math(), &sc->sc_used_math); + + if (used_math()) { + /* + * Save FPU state to signal context. Signal handler + * will "inherit" current FPU state. + */ + preempt_disable(); + + if (!is_fpu_owner()) { + own_fpu(); + restore_fp(current); + } + err |= save_fp_context(sc); + + preempt_enable(); + } + return err; +} + +int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) +{ + unsigned int used_math; + unsigned long treg; + int err = 0; + int i; + + /* Always make any pending restarted system calls return -EINTR */ + current_thread_info()->restart_block.fn = do_no_restart_syscall; + + err |= __get_user(regs->cp0_epc, &sc->sc_pc); + err |= __get_user(regs->hi, &sc->sc_mdhi); + err |= __get_user(regs->lo, &sc->sc_mdlo); + if (cpu_has_dsp) { + err |= __get_user(treg, &sc->sc_hi1); mthi1(treg); + err |= __get_user(treg, &sc->sc_lo1); mtlo1(treg); + err |= __get_user(treg, &sc->sc_hi2); mthi2(treg); + err |= __get_user(treg, &sc->sc_lo2); mtlo2(treg); + err |= __get_user(treg, &sc->sc_hi3); mthi3(treg); + err |= __get_user(treg, &sc->sc_lo3); mtlo3(treg); + err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); + } + + for (i = 1; i < 32; i++) + err |= __get_user(regs->regs[i], &sc->sc_regs[i]); + + err |= __get_user(used_math, &sc->sc_used_math); + conditional_used_math(used_math); + + preempt_disable(); + + if (used_math()) { + /* restore fpu context if we have used it before */ + own_fpu(); + err |= restore_fp_context(sc); + } else { + /* signal handler may have used FPU. Give it up. */ + lose_fpu(); + } + + preempt_enable(); + + return err; +} + +void __user *get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, + size_t frame_size) +{ + unsigned long sp; + + /* Default to using normal stack */ + sp = regs->regs[29]; + + /* + * FPU emulator may have it's own trampoline active just + * above the user stack, 16-bytes before the next lowest + * 16 byte boundary. Try to avoid trashing it. + */ + sp -= 32; + + /* This is the X/Open sanctioned signal stack switching. */ + if ((ka->sa.sa_flags & SA_ONSTACK) && (sas_ss_flags (sp) == 0)) + sp = current->sas_ss_sp + current->sas_ss_size; + + return (void __user *)((sp - frame_size) & (ICACHE_REFILLS_WORKAROUND_WAR ? ~(cpu_icache_line_size()-1) : ALMASK)); +} + +int install_sigtramp(unsigned int __user *tramp, unsigned int syscall) +{ + int err; + + /* + * Set up the return code ... + * + * li v0, __NR__foo_sigreturn + * syscall + */ + + err = __put_user(0x24020000 + syscall, tramp + 0); + err |= __put_user(0x0000000c , tramp + 1); + if (ICACHE_REFILLS_WORKAROUND_WAR) { + err |= __put_user(0, tramp + 2); + err |= __put_user(0, tramp + 3); + err |= __put_user(0, tramp + 4); + err |= __put_user(0, tramp + 5); + err |= __put_user(0, tramp + 6); + err |= __put_user(0, tramp + 7); + } + flush_cache_sigtramp((unsigned long) tramp); + + return err; +} + +/* * Atomically swap in the new signal mask, and wait for a signal. */ -- 1.4.4.3.ge6d4 From ralf@linux-mips.org Mon Feb 5 18:29:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 18:29:01 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:46983 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037752AbXBES3A (ORCPT ); Mon, 5 Feb 2007 18:29:00 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l15IStQJ025255; Mon, 5 Feb 2007 18:28:56 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l15IStcK025254; Mon, 5 Feb 2007 18:28:55 GMT Date: Mon, 5 Feb 2007 18:28:55 +0000 From: Ralf Baechle To: "Ahmed S. Darwish" Cc: linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH 2.6.20] arch MIPS: user ARRAY_SIZE macro when appropriate Message-ID: <20070205182855.GA24794@linux-mips.org> References: <20070205023935.GG18118@Ahmed> <20070205024211.GK18118@Ahmed> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205024211.GK18118@Ahmed> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13939 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 161 Lines: 7 On Mon, Feb 05, 2007 at 04:42:11AM +0200, Ahmed S. Darwish wrote: > A patch to use ARRAY_SIZE macro already defined in linux/kernel.h Thanks, applied. Ralf From Marc_St-Jean@pmc-sierra.com Mon Feb 5 18:47:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 18:47:47 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:2232 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20037753AbXBESrj (ORCPT ); Mon, 5 Feb 2007 18:47:39 +0000 Received: (qmail 18474 invoked by uid 101); 5 Feb 2007 18:46:08 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by father.pmc-sierra.com with SMTP; 5 Feb 2007 18:46:08 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l15Ik7oY004282; Mon, 5 Feb 2007 10:46:07 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7P2VK>; Mon, 5 Feb 2007 10:46:07 -0800 Message-ID: <45C77B61.1080209@pmc-sierra.com> From: Marc St-Jean To: linux-serial@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Date: Mon, 5 Feb 2007 10:45:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 05 Feb 2007 18:45:53.0270 (UTC) FILETIME=[DD083960:01C74955] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13940 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Content-Length: 5841 Lines: 173 Third attempt at the serial driver patch for the PMC-Sierra MSP71xx device. There are three different fixes: 1. Fix for DesignWare THRE errata - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" tree also fixes it. This patch needs to be applied on top of it. 2. Fix for Busy Detect on LCR write - Dropped the addition of UPIO_DWAPB iotype to 8250_early.c as Sergei pointed out the fix wasn't complete and we don't require it. 3. Workaround for interrupt/data concurrency issue - Fix must remain serial8250_interrupt() in order to mark interrupt as handled. Thanks, Marc Signed-off-by: Marc St-Jean diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 3d91bfc..489ff2b 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar return inb(up->port.iobase + 1); case UPIO_MEM: + case UPIO_DWAPB: return readb(up->port.membase + offset); case UPIO_MEM32: @@ -333,6 +334,8 @@ #endif static void serial_out(struct uart_8250_port *up, int offset, int value) { + /* Save the offset before it's remapped */ + int save_offset = offset; offset = map_8250_out_reg(up, offset) << up->port.regshift; switch (up->port.iotype) { @@ -359,6 +362,18 @@ #endif writeb(value, up->port.membase + offset); break; + case UPIO_DWAPB: + /* Save the LCR value so it can be re-written when a + * Busy Detect interrupt occurs. */ + if (save_offset == UART_LCR) + up->lcr = value; + writeb(value, up->port.membase + offset); + /* Read the IER to ensure any interrupt is cleared before + * returning from ISR. */ + if ((save_offset == UART_TX || save_offset == UART_IER) && in_irq()) + value = serial_in(up, UART_IER); + break; + default: outb(value, up->port.iobase + offset); } @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u #ifdef CONFIG_SERIAL_8250_AU1X00 case UPIO_AU: #endif + case UPIO_DWAPB: serial_out(up, offset, value); (void)serial_in(up, UART_LCR); /* safe, no side-effects */ break; @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( handled = 1; end = NULL; + } else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY && + up->port.iotype == UPIO_DWAPB) { + /* The DesignWare APB UART has an Busy Detect (0x07) + * interrupt meaning an LCR write attempt occured while the + * UART was busy. The interrupt must be cleared by reading + * the UART status register (USR) and the LCR re-written. */ + unsigned int status; + status = *(volatile u32 *)up->port.data; + serial_out(up, UART_LCR, up->lcr); + + handled = 1; + + end = NULL; } else if (end == NULL) end = l; @@ -2085,6 +2114,7 @@ static int serial8250_request_std_resour case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2122,6 +2152,7 @@ static void serial8250_release_std_resou case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2454,9 +2485,12 @@ int __init serial8250_start_console(stru add_preferred_console("ttyS", line, options); printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : - (unsigned long) port->iobase, options); + line, + (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB) + ? "MMIO" : "I/O port", + (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB) + ? (unsigned long) port->mapbase : (unsigned long) port->iobase, + options); if (!(serial8250_console.flags & CON_ENABLED)) { serial8250_console.flags &= ~CON_PRINTBUFFER; register_console(&serial8250_console); diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c index f84982e..f5b6036 100644 --- a/drivers/serial/serial_core.c +++ b/drivers/serial/serial_core.c @@ -2057,6 +2057,7 @@ uart_report_port(struct uart_driver *drv case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: snprintf(address, sizeof(address), "MMIO 0x%lx", port->mapbase); break; @@ -2401,6 +2402,7 @@ int uart_match_port(struct uart_port *po case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: return (port1->mapbase == port2->mapbase); } return 0; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index cf23813..9cb9b3b 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -230,6 +230,7 @@ #define UPIO_MEM (2) #define UPIO_MEM32 (3) #define UPIO_AU (4) /* Au1x00 type IO */ #define UPIO_TSI (5) /* Tsi108/109 type IO */ +#define UPIO_DWAPB (6) /* DesignWare APB UART */ unsigned int read_status_mask; /* driver specific */ unsigned int ignore_status_mask; /* driver specific */ @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( struct device *dev; /* parent device */ unsigned char hub6; /* this should be in the 8250 driver */ unsigned char unused[3]; + void *data; /* generic platform data pointer */ }; /* diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 3c8a6aa..b3550cc 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -37,6 +37,7 @@ #define UART_IIR_MSI 0x00 /* Modem stat #define UART_IIR_THRI 0x02 /* Transmitter holding register empty */ #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ From Marc_St-Jean@pmc-sierra.com Mon Feb 5 20:43:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 20:43:08 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:4312 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20037724AbXBEUnC (ORCPT ); Mon, 5 Feb 2007 20:43:02 +0000 Received: (qmail 28295 invoked by uid 101); 5 Feb 2007 20:41:42 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by father.pmc-sierra.com with SMTP; 5 Feb 2007 20:41:42 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l15Kfgsw014415 for ; Mon, 5 Feb 2007 12:41:42 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7PNGC>; Mon, 5 Feb 2007 12:41:41 -0800 Message-ID: <45C7967E.1090505@pmc-sierra.com> From: Marc St-Jean To: linux-mips@linux-mips.org Subject: Embedding rootfs with kernel Date: Mon, 5 Feb 2007 12:41:34 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 05 Feb 2007 20:41:34.0648 (UTC) FILETIME=[066A7380:01C74966] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13941 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Content-Length: 603 Lines: 16 What is the MIPS-way of embedding the rootfs with the kernel? Our method involves modifying the vmlinux.lds.S linker script to pull in our 'romfs' section. I don't see any other platform code doing this so there must be a more "standard" approach. Apparently there was support in linux 2.4 (a patch possibly?) which would look for supported file system magic numbers past the end of the kernel. So you could just cat the rootfs to the end of the kernel binary and go on with life. I've tried this with linux-mips.org code base and it doesn't appear to work. Any pointers would be appreciated. Marc From alan@lxorguk.ukuu.org.uk Mon Feb 5 21:48:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 05 Feb 2007 21:48:22 +0000 (GMT) Received: from outpipe-village-512-1.bc.nu ([81.2.110.250]:42387 "EHLO lxorguk.ukuu.org.uk") by ftp.linux-mips.org with ESMTP id S20027541AbXBEVsS (ORCPT ); Mon, 5 Feb 2007 21:48:18 +0000 Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by lxorguk.ukuu.org.uk (8.13.8/8.13.4) with ESMTP id l15Lx1IK011259; Mon, 5 Feb 2007 21:59:02 GMT Date: Mon, 5 Feb 2007 21:59:01 +0000 From: Alan To: Marc St-Jean Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Message-ID: <20070205215901.7344c954@localhost.localdomain> In-Reply-To: <45C77B61.1080209@pmc-sierra.com> References: <45C77B61.1080209@pmc-sierra.com> X-Mailer: Claws Mail 2.7.1 (GTK+ 2.10.4; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13942 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: alan@lxorguk.ukuu.org.uk Precedence: bulk X-list: linux-mips Content-Length: 893 Lines: 23 > unsigned char hub6; /* this should be in the 8250 driver */ > unsigned char unused[3]; > + void *data; /* generic platform data pointer */ > }; Convention is "private_data" > > /* > diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h > index 3c8a6aa..b3550cc 100644 > --- a/include/linux/serial_reg.h > +++ b/include/linux/serial_reg.h > @@ -37,6 +37,7 @@ #define UART_IIR_MSI 0x00 /* Modem stat > #define UART_IIR_THRI 0x02 /* Transmitter holding register empty */ > #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ > #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ > +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ Please move this down a line to break it from "official" values and call it DESIGNWARE_UART_IIR_BUSY, so it is obviously designware specific. Otherwise looks much less invasive and messy From yoichi_yuasa@tripeaks.co.jp Tue Feb 6 02:00:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 02:00:50 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:60487 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20038814AbXBFCAp (ORCPT ); Tue, 6 Feb 2007 02:00:45 +0000 Received: by mo.po.2iij.net (mo31) id l161xMUd081328; Tue, 6 Feb 2007 10:59:22 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox33) id l161xM59075711 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Tue, 6 Feb 2007 10:59:22 +0900 (JST) Message-Id: <200702060159.l161xM59075711@mbox33.po.2iij.net> Date: Tue, 6 Feb 2007 10:59:22 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] fix run_uncached warning about 32bit kernel Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13943 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Content-Length: 1619 Lines: 42 Hi Ralf, This patch has fixed warning about 32 bit kernel. arch/mips/lib/uncached.c: In function 'run_uncached': arch/mips/lib/uncached.c:47: warning: comparison is always true due to limited range of data type arch/mips/lib/uncached.c:48: warning: comparison is always false due to limited range of data type arch/mips/lib/uncached.c:57: warning: comparison is always true due to limited range of data type arch/mips/lib/uncached.c:58: warning: comparison is always false due to limited range of data type Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/lib/uncached.c mips/arch/mips/lib/uncached.c --- mips-orig/arch/mips/lib/uncached.c 2006-11-13 19:32:04.002117500 +0900 +++ mips/arch/mips/lib/uncached.c 2006-11-13 19:29:07.087061000 +0900 @@ -44,20 +44,24 @@ unsigned long __init run_uncached(void * if (sp >= (long)CKSEG0 && sp < (long)CKSEG2) usp = CKSEG1ADDR(sp); +#ifdef CONFIG_64BIT else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0) && (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0)) usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED, XKPHYS_TO_PHYS((long long)sp)); +#endif else { BUG(); usp = sp; } if (lfunc >= (long)CKSEG0 && lfunc < (long)CKSEG2) ufunc = CKSEG1ADDR(lfunc); +#ifdef CONFIG_64BIT else if ((long long)lfunc >= (long long)PHYS_TO_XKPHYS(0LL, 0) && (long long)lfunc < (long long)PHYS_TO_XKPHYS(8LL, 0)) ufunc = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED, XKPHYS_TO_PHYS((long long)lfunc)); +#endif else { BUG(); ufunc = lfunc; From domen.puncer@telargo.com Tue Feb 6 06:49:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 06:50:02 +0000 (GMT) Received: from out001.atlarge.net ([129.41.63.69]:48138 "EHLO out001.atlarge.net") by ftp.linux-mips.org with ESMTP id S20037863AbXBFGtz (ORCPT ); Tue, 6 Feb 2007 06:49:55 +0000 Received: from hpmailfe-01.atlarge.net ([10.100.60.156]) by out001.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 00:47:28 -0600 Received: from localhost ([213.250.36.225]) by hpmailfe-01.atlarge.net with Microsoft SMTPSVC(6.0.3790.1830); Tue, 6 Feb 2007 00:47:27 -0600 Date: Tue, 6 Feb 2007 07:49:17 +0100 From: Domen Puncer To: Marc St-Jean Cc: linux-mips@linux-mips.org Subject: Re: Embedding rootfs with kernel Message-ID: <20070206064917.GJ4397@moe.telargo.com> References: <45C7967E.1090505@pmc-sierra.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45C7967E.1090505@pmc-sierra.com> User-Agent: Mutt/1.5.12-2006-07-14 X-OriginalArrivalTime: 06 Feb 2007 06:47:27.0797 (UTC) FILETIME=[AA94C650:01C749BA] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13944 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: domen.puncer@telargo.com Precedence: bulk X-list: linux-mips Content-Length: 164 Lines: 7 On 05/02/07 12:41 -0800, Marc St-Jean wrote: > What is the MIPS-way of embedding the rootfs with the kernel? For 2.6.x (on all? architectures) initramfs. Domen From anemo@mba.ocn.ne.jp Tue Feb 6 07:02:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 07:03:01 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:55500 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037871AbXBFHCy (ORCPT ); Tue, 6 Feb 2007 07:02:54 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Tue, 6 Feb 2007 16:02:48 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 4F11E420CF; Tue, 6 Feb 2007 16:02:22 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 3AB4C203A7; Tue, 6 Feb 2007 16:02:22 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l1672LW0057784; Tue, 6 Feb 2007 16:02:21 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Tue, 06 Feb 2007 16:02:21 +0900 (JST) Message-Id: <20070206.160221.07643905.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [MIPS] Work around bogus gcc warnings. From: Atsushi Nemoto In-Reply-To: References: X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13945 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Content-Length: 1188 Lines: 38 On Thu, 30 Nov 2006 01:22:47 +0000, linux-mips@linux-mips.org wrote: > Author: Ralf Baechle Thu Nov 30 00:14:48 2006 +0000 > Commit: df300391b4833167841465189f6ef32560f0282d > Gitweb: http://www.linux-mips.org/g/linux/df300391 > Branch: master > > Signed-off-by: Ralf Baechle > > --- > > arch/mips/kernel/traps.c | 43 ++++++++++++++++++++++--------------------- > 1 files changed, 22 insertions(+), 21 deletions(-) This commit broke gdb, since any BREAK or TRAP instruction cause SIGSEGV. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 2a932ca..cfd1785 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -708,6 +708,7 @@ asmlinkage void do_bp(struct pt_regs *regs) die_if_kernel("Break instruction in kernel code", regs); force_sig(SIGTRAP, current); } + return; out_sigsegv: force_sig(SIGSEGV, current); @@ -751,6 +752,7 @@ asmlinkage void do_tr(struct pt_regs *regs) die_if_kernel("Trap instruction in kernel code", regs); force_sig(SIGTRAP, current); } + return; out_sigsegv: force_sig(SIGSEGV, current); From ralf@linux-mips.org Tue Feb 6 11:04:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 11:04:05 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:18097 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037836AbXBFLEE (ORCPT ); Tue, 6 Feb 2007 11:04:04 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l16B3wJL006734; Tue, 6 Feb 2007 11:03:58 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l16B3wFn006733; Tue, 6 Feb 2007 11:03:58 GMT Date: Tue, 6 Feb 2007 11:03:58 +0000 From: Ralf Baechle To: "Koeller, T." Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Remove Basler Excite support Message-ID: <20070206110358.GA29286@linux-mips.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13946 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Content-Length: 1479 Lines: 24 On Mon, Feb 05, 2007 at 11:35:55AM +0100, Koeller, T. wrote: > the last time I worked on it (which is three days ago, while working to make the excite nand flash driver ready for submission), it built and ran just fine, so I really wonder why you are removing it. I now notice that it has been made depending on BROKEN some time ago, which escaped my attention when it happened. It was marked broken because in the incomplete merge state it did not build. My last emails did not receive any answer and the patch to remove it has actually been sitting in the queue tree for well over a month mostly as hint by waiving with a tree trunk so I did interpret this as a loss of communication. > The reason I did not encounter any build problems is that I always built the code with the yet-to-be-submitted drivers. The compilation error you get when building the excite platform is caused by a dependency upon the rm9k_serial driver, on which the platform depends for serial console support. I haven't yet managed to submit that driver, although I made several attempts. If serial console support were disabled, the code could trivially be fixed to compile without errors. 2.6.21 has just opened so now is an excellent time to submit all the remaining driver bits. > Can you revert the removal? Sure, I can undo the deletion at any time. And to generalize that, while I'm eager to remove code for which nobody has shown any interest this by no means is a one way road. Ralf From ralf@linux-mips.org Tue Feb 6 11:51:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 11:51:03 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:55714 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037857AbXBFLvB (ORCPT ); Tue, 6 Feb 2007 11:51:01 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l16Bp0xE008054; Tue, 6 Feb 2007 11:51:00 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l16BoxH0008053; Tue, 6 Feb 2007 11:50:59 GMT Date: Tue, 6 Feb 2007 11:50:59 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Work around bogus gcc warnings. Message-ID: <20070206115059.GA5660@linux-mips.org> References: <20070206.160221.07643905.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070206.160221.07643905.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13947 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 06, 2007 at 04:02:21PM +0900, Atsushi Nemoto wrote: > This commit broke gdb, since any BREAK or TRAP instruction cause > SIGSEGV. Applied, thanks. Ralf From ralf@linux-mips.org Tue Feb 6 15:28:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 15:28:21 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:24537 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038419AbXBFP2T (ORCPT ); Tue, 6 Feb 2007 15:28:19 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l16FSJa8031973; Tue, 6 Feb 2007 15:28:19 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l16FSHAq031972; Tue, 6 Feb 2007 15:28:17 GMT Date: Tue, 6 Feb 2007 15:28:17 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] fix run_uncached warning about 32bit kernel Message-ID: <20070206152817.GB5660@linux-mips.org> References: <200702060159.l161xM59075711@mbox33.po.2iij.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702060159.l161xM59075711@mbox33.po.2iij.net> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13948 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 06, 2007 at 10:59:22AM +0900, Yoichi Yuasa wrote: > arch/mips/lib/uncached.c: In function 'run_uncached': > arch/mips/lib/uncached.c:47: warning: comparison is always true due to limited range of data type > arch/mips/lib/uncached.c:48: warning: comparison is always false due to limited range of data type > arch/mips/lib/uncached.c:57: warning: comparison is always true due to limited range of data type > arch/mips/lib/uncached.c:58: warning: comparison is always false due to limited range of data type Thanks, applied. Ralf From vagabon.xyz@gmail.com Tue Feb 6 15:55:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 15:55:31 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.236]:49953 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038431AbXBFPz0 (ORCPT ); Tue, 6 Feb 2007 15:55:26 +0000 Received: by hu-out-0506.google.com with SMTP id 22so985449hug for ; Tue, 06 Feb 2007 07:54:25 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=KwHe7wK7c6sSKeF6pB/UVCQzAd6O6p8CC/mmdqOvXHQyeEh6m5TjcQtlaff/u3MwovHLGSJgK3ECWClZqm0Qq/trjYSBdg0peYq4vdSpf8R/hHOLOOfTtl4DoMJ074YxPVSeasuJPGI4V5RIBv18zUk11LrP/om3An4T1WdnsfQ= Received: by 10.78.172.20 with SMTP id u20mr531657hue.1170777265690; Tue, 06 Feb 2007 07:54:25 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id q28sm2872148nfc.2007.02.06.07.54.24; Tue, 06 Feb 2007 07:54:25 -0800 (PST) Message-ID: <45C8A477.8070906@innova-card.com> Date: Tue, 06 Feb 2007 16:53:27 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: [PATCH] clean up ret_from_{irq,exception} Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13949 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This patch makes these routines a lot more readable whatever the value of CONFIG_PREEMPT. It also moves one branch instruction from ret_from_irq() to ret_from_exception(). Therefore we favour the return from irq path which should be more common than the other one. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/entry.S | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S index f10b6a1..571029b 100644 --- a/arch/mips/kernel/entry.S +++ b/arch/mips/kernel/entry.S @@ -21,23 +21,18 @@ #endif #ifndef CONFIG_PREEMPT - .macro preempt_stop - local_irq_disable - .endm #define resume_kernel restore_all #endif .text .align 5 -FEXPORT(ret_from_irq) - LONG_S s0, TI_REGS($28) -#ifdef CONFIG_PREEMPT -FEXPORT(ret_from_exception) -#else - b _ret_from_irq FEXPORT(ret_from_exception) - preempt_stop +#ifndef CONFIG_PREEMPT + local_irq_disable # preempt stop #endif + b _ret_from_irq +FEXPORT(ret_from_irq) + LONG_S s0, TI_REGS($28) FEXPORT(_ret_from_irq) LONG_L t0, PT_STATUS(sp) # returning to kernel mode? andi t0, t0, KU_USER -- 1.4.4.3.ge6d4 From Marc_St-Jean@pmc-sierra.com Tue Feb 6 16:54:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 16:54:07 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:64717 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20038440AbXBFQyC (ORCPT ); Tue, 6 Feb 2007 16:54:02 +0000 Received: (qmail 16814 invoked by uid 101); 6 Feb 2007 16:52:50 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by father.pmc-sierra.com with SMTP; 6 Feb 2007 16:52:50 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l16GqW5v024492; Tue, 6 Feb 2007 08:52:41 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7QLJC>; Tue, 6 Feb 2007 08:52:32 -0800 Message-ID: <45C8B24B.1000204@pmc-sierra.com> From: Marc St-Jean To: Alan Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Tue, 6 Feb 2007 08:52:27 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 06 Feb 2007 16:52:28.0427 (UTC) FILETIME=[2F7155B0:01C74A0F] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13950 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Thank Alan. I made the changes yesterday but I'll wait another day before reposting, in case other interested people have more comments. Marc Alan wrote: > > unsigned char hub6; /* this should > be in the 8250 driver */ > > unsigned char unused[3]; > > + void *data; /* > generic platform data pointer */ > > }; > > Convention is "private_data" > > > > > /* > > diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h > > index 3c8a6aa..b3550cc 100644 > > --- a/include/linux/serial_reg.h > > +++ b/include/linux/serial_reg.h > > @@ -37,6 +37,7 @@ #define UART_IIR_MSI 0x00 /* Modem stat > > #define UART_IIR_THRI 0x02 /* Transmitter holding > register empty */ > > #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ > > #define UART_IIR_RLSI 0x06 /* Receiver line status > interrupt */ > > +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy > Detect */ > > Please move this down a line to break it from "official" values and call > it DESIGNWARE_UART_IIR_BUSY, so it is obviously designware specific. > > Otherwise looks much less invasive and messy > From Marc_St-Jean@pmc-sierra.com Tue Feb 6 17:01:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 17:01:15 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:38639 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20038432AbXBFRBK (ORCPT ); Tue, 6 Feb 2007 17:01:10 +0000 Received: (qmail 6768 invoked by uid 101); 6 Feb 2007 17:00:02 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by mother.pmc-sierra.com with SMTP; 6 Feb 2007 17:00:02 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l16H009Z025406; Tue, 6 Feb 2007 09:00:02 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7QLV8>; Tue, 6 Feb 2007 08:59:59 -0800 Message-ID: <45C8B408.4050203@pmc-sierra.com> From: Marc St-Jean To: Domen Puncer Cc: linux-mips@linux-mips.org Subject: Re: Embedding rootfs with kernel Date: Tue, 6 Feb 2007 08:59:53 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 06 Feb 2007 16:59:53.0268 (UTC) FILETIME=[3896AF40:01C74A10] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13951 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips I was also looking at initramfs but from documentation I found it, appears to expand the cpio.gz into a tmpfs (i.e. RAM) before using it. Since the cpio.gz is embedded into the kernel (i.e. RAM again), won't this take twice the memory relative to embedding a cramfs/squashfs directly in the kernel? We only need read-only access and I believe these file systems can be read in their compressed form without expanding and consuming more RAM. Marc Domen Puncer wrote: > On 05/02/07 12:41 -0800, Marc St-Jean wrote: > > What is the MIPS-way of embedding the rootfs with the kernel? > > For 2.6.x (on all? architectures) initramfs. > > > Domen > From macro@linux-mips.org Tue Feb 6 18:21:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 18:21:22 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:10502 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038453AbXBFSVR (ORCPT ); Tue, 6 Feb 2007 18:21:17 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id B5CDEE1CA0; Tue, 6 Feb 2007 19:20:31 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hA1F6ShoORnV; Tue, 6 Feb 2007 19:20:31 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 58003E1C84; Tue, 6 Feb 2007 19:20:31 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l16IKiU4022676; Tue, 6 Feb 2007 19:20:44 +0100 Date: Tue, 6 Feb 2007 18:20:39 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Yoichi Yuasa , linux-mips Subject: Re: [PATCH][MIPS] fix run_uncached warning about 32bit kernel In-Reply-To: <20070206152817.GB5660@linux-mips.org> Message-ID: References: <200702060159.l161xM59075711@mbox33.po.2iij.net> <20070206152817.GB5660@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2527/Tue Feb 6 11:14:46 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13952 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, 6 Feb 2007, Ralf Baechle wrote: > On Tue, Feb 06, 2007 at 10:59:22AM +0900, Yoichi Yuasa wrote: > > > arch/mips/lib/uncached.c: In function 'run_uncached': > > arch/mips/lib/uncached.c:47: warning: comparison is always true due to limited range of data type > > arch/mips/lib/uncached.c:48: warning: comparison is always false due to limited range of data type > > arch/mips/lib/uncached.c:57: warning: comparison is always true due to limited range of data type > > arch/mips/lib/uncached.c:58: warning: comparison is always false due to limited range of data type > > Thanks, applied. "Fixing" bugs in the compiler, huh? ;-) I suppose there should be a note somewhere nearby then, so there is a remote chance to remove the clutter in the future. Maciej From Marc_St-Jean@pmc-sierra.com Tue Feb 6 19:04:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 06 Feb 2007 19:04:39 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:34968 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20038469AbXBFTEc (ORCPT ); Tue, 6 Feb 2007 19:04:32 +0000 Received: (qmail 16181 invoked by uid 101); 6 Feb 2007 19:03:15 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by mother.pmc-sierra.com with SMTP; 6 Feb 2007 19:03:15 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l16J3Eu9004447; Tue, 6 Feb 2007 11:03:14 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7QRAW>; Tue, 6 Feb 2007 11:03:14 -0800 Message-ID: <45C8D0EC.2060007@pmc-sierra.com> From: Marc St-Jean To: linux-mips@linux-mips.org Subject: Re: Embedding rootfs with kernel Date: Tue, 6 Feb 2007 11:03:08 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 06 Feb 2007 19:03:09.0088 (UTC) FILETIME=[70D74200:01C74A21] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13953 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Alexander Voropay wrote: > > > >I was also looking at initramfs but from documentation I found it, > > appears to expand the cpio.gz into a tmpfs (i.e. RAM) before using > > it. > > Read this nice article: > http://www.linuxdevices.com/articles/AT4017834659.html > Thanks Alexander, I'd read it many months ago, it does clarifies a few issues. Another article on various methods of preparing the initramfs is: "Including an initramfs Intialization Program in the Kernel" http://lldn.timesys.com/docs/initramfs?elq=1EE1D775A62A4EF68F0A3E9AEC666D0D Neither of these seem to help with regards to embedding a read-only file system. It seems like there is no officially supported way of doing this. Presumably these types of file systems are meant to only be used separate from the kernel image, such as in a flash partition. I guess we can continue to use our current method, but I was hoping to eliminate any changes to non-platform code such as vmlinux.lds.S. Marc From anemo@mba.ocn.ne.jp Wed Feb 7 04:38:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 04:38:40 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:42697 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20037419AbXBGEig (ORCPT ); Wed, 7 Feb 2007 04:38:36 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 7 Feb 2007 13:38:34 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id F3BE041DA1 for ; Wed, 7 Feb 2007 13:38:09 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id E744E206AB for ; Wed, 7 Feb 2007 13:38:09 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l174c9W0062264 for ; Wed, 7 Feb 2007 13:38:09 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 07 Feb 2007 13:38:09 +0900 (JST) Message-Id: <20070207.133809.71085888.nemoto@toshiba-tops.co.jp> To: linux-mips@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: References: X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13954 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 05 Feb 2007 16:12:26 +0000, linux-mips@linux-mips.org wrote: > Author: Chris Dearman Thu Feb 1 19:54:13 2007 +0000 > Comitter: Ralf Baechle Mon Feb 5 15:56:18 2007 +0000 > Commit: a9e080c2c615bc4e9d9987330c0be35ea5226eed > Gitweb: http://www.linux-mips.org/g/linux/a9e080c2 > Branch: master > > Signed-off-by: Chris Dearman > Signed-off-by: Ralf Baechle > > --- > > arch/mips/kernel/r4k_fpu.S | 16 ++++++++++++++++ > 1 files changed, 16 insertions(+), 0 deletions(-) r2300_fpu.S and r6000_fpu.S should be fixed too? Also, fpu_emulator_restore_context() should check FCSR too? (it should not harm FPU-less CPU, but on MIPS_MT, FCSR value restored by fpu emulator might be used for real FPU, right?) --- Atsushi Nemoto From ralf@linux-mips.org Wed Feb 7 11:09:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 11:09:33 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:57998 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038685AbXBGLJc (ORCPT ); Wed, 7 Feb 2007 11:09:32 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l17B9UPN018503; Wed, 7 Feb 2007 11:09:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l17B9TdX018502; Wed, 7 Feb 2007 11:09:29 GMT Date: Wed, 7 Feb 2007 11:09:29 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. Message-ID: <20070207110929.GA17660@linux-mips.org> References: <20070207.133809.71085888.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070207.133809.71085888.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13955 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 07, 2007 at 01:38:09PM +0900, Atsushi Nemoto wrote: > > arch/mips/kernel/r4k_fpu.S | 16 ++++++++++++++++ > > 1 files changed, 16 insertions(+), 0 deletions(-) > > r2300_fpu.S and r6000_fpu.S should be fixed too? > > Also, fpu_emulator_restore_context() should check FCSR too? (it should > not harm FPU-less CPU, but on MIPS_MT, FCSR value restored by fpu > emulator might be used for real FPU, right?) Correct in all points. Ralf From anemo@mba.ocn.ne.jp Wed Feb 7 15:42:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 15:42:17 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:45022 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039193AbXBGPmL (ORCPT ); Wed, 7 Feb 2007 15:42:11 +0000 Received: from localhost (p4022-ipad202funabasi.chiba.ocn.ne.jp [222.146.75.22]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 3FAA6C159; Thu, 8 Feb 2007 00:40:50 +0900 (JST) Date: Thu, 08 Feb 2007 00:40:49 +0900 (JST) Message-Id: <20070208.004049.51866970.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, fbuihuu@gmail.com Subject: Re: [PATCH 9/10] signal: do not use save_static_function() anymore From: Atsushi Nemoto In-Reply-To: <11706854703880-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> <11706854703880-git-send-email-fbuihuu@gmail.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13956 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 5 Feb 2007 15:24:27 +0100, Franck Bui-Huu wrote: > For the sys_sigsuspend() case, I don't see any reasons... Maybe that was needed before commit 7b3e2fc847c8325a7b35185fa1fc2f1729ed9c5b. At that time sys_sigsuspend() called do_signal() (which includes setup_sigcontext()) directly. So all registers must be saved to kernel stack. Now do_signal() is called only from do_notify_resume(), so I agree save_static_function is not needed. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Feb 7 16:05:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 16:05:55 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:52431 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039488AbXBGQFu (ORCPT ); Wed, 7 Feb 2007 16:05:50 +0000 Received: from localhost (p4022-ipad202funabasi.chiba.ocn.ne.jp [222.146.75.22]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 95BAF8DD1; Thu, 8 Feb 2007 01:04:30 +0900 (JST) Date: Thu, 08 Feb 2007 01:04:30 +0900 (JST) Message-Id: <20070208.010430.58789357.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 0/10] Clean up signal code [take #3] From: Atsushi Nemoto In-Reply-To: <11706854683935-git-send-email-fbuihuu@gmail.com> References: <11706854683935-git-send-email-fbuihuu@gmail.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13957 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 5 Feb 2007 15:24:18 +0100, Franck Bui-Huu wrote: > Here is the third version of this patchset. > I ran (on a 32-bits kernel _only_) all LTP signal testcases and > they all passed. I haven't time to look at what these tests exactly > do though. Thank you for good job. All looks good for me. # Though [PATCH 6/10] failed due to recent whitespace cleanup ... I hope this patchset applied before updating my fp_context patches. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Feb 7 16:12:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 16:12:14 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:62957 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039496AbXBGQMI (ORCPT ); Wed, 7 Feb 2007 16:12:08 +0000 Received: from localhost (p4022-ipad202funabasi.chiba.ocn.ne.jp [222.146.75.22]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 8539784F5; Thu, 8 Feb 2007 01:10:40 +0900 (JST) Date: Thu, 08 Feb 2007 01:10:40 +0900 (JST) Message-Id: <20070208.011040.112287201.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org Subject: Re: [PATCH 1/3] do_fpe() cleanup From: Atsushi Nemoto In-Reply-To: <20061125.000344.03977447.anemo@mba.ocn.ne.jp> References: <20061125.000344.03977447.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13958 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sat, 25 Nov 2006 00:03:44 +0900 (JST), Atsushi Nemoto wrote: > If we had already lost FPU before disabling preempt, we do not have to > own it at all. And we do not prevent preemption when managing saved > FCR31 if we did not have FPU ownership. > > Signed-off-by: Atsushi Nemoto > --- > traps.c | 22 ++++++++-------------- > 1 files changed, 8 insertions(+), 14 deletions(-) Ping. This patch is dependent from other fp_context patches and should be safe and harmless. Are there any problems? diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 9fda1b8..b18aeb6 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -614,16 +614,6 @@ asmlinkage void do_fpe(struct pt_regs *r if (fcr31 & FPU_CSR_UNI_X) { int sig; - preempt_disable(); - -#ifdef CONFIG_PREEMPT - if (!is_fpu_owner()) { - /* We might lose fpu before disabling preempt... */ - own_fpu(); - BUG_ON(!used_math()); - restore_fp(current); - } -#endif /* * Unimplemented operation exception. If we've got the full * software emulator on-board, let's use it... @@ -634,7 +624,11 @@ #endif * register operands before invoking the emulator, which seems * a bit extreme for what should be an infrequent event. */ - save_fp(current); + preempt_disable(); + + /* We might have lost fpu before disabling preempt... */ + if (is_fpu_owner()) + save_fp(current); /* Ensure 'resume' not overwrite saved fp context again. */ lose_fpu(); @@ -643,15 +637,15 @@ #endif /* Run the emulator */ sig = fpu_emulator_cop1Handler (regs, ¤t->thread.fpu, 1); - preempt_disable(); - - own_fpu(); /* Using the FPU again. */ /* * We can't allow the emulated instruction to leave any of * the cause bit set in $fcr31. */ current->thread.fpu.fcr31 &= ~FPU_CSR_ALL_X; + preempt_disable(); + + own_fpu(); /* Using the FPU again. */ /* Restore the hardware register state */ restore_fp(current); From anemo@mba.ocn.ne.jp Wed Feb 7 16:23:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 16:23:42 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:27346 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039534AbXBGQXg (ORCPT ); Wed, 7 Feb 2007 16:23:36 +0000 Received: from localhost (p4022-ipad202funabasi.chiba.ocn.ne.jp [222.146.75.22]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id DD5BDBC4C; Thu, 8 Feb 2007 01:22:16 +0900 (JST) Date: Thu, 08 Feb 2007 01:22:16 +0900 (JST) Message-Id: <20070208.012216.103777705.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: <20070207110929.GA17660@linux-mips.org> References: <20070207.133809.71085888.nemoto@toshiba-tops.co.jp> <20070207110929.GA17660@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13959 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 7 Feb 2007 11:09:29 +0000, Ralf Baechle wrote: > > r2300_fpu.S and r6000_fpu.S should be fixed too? > > > > Also, fpu_emulator_restore_context() should check FCSR too? (it should > > not harm FPU-less CPU, but on MIPS_MT, FCSR value restored by fpu > > emulator might be used for real FPU, right?) > > Correct in all points. If the format of FCSR was common to all CPU (I hope so), we can do check it in caller of fp_restore_context(), in C language. BTW, why R6000 does not use r4k_fpu.S? --- Atsushi Nemoto From macro@linux-mips.org Wed Feb 7 17:29:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 17:29:46 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:7442 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20039477AbXBGR3k (ORCPT ); Wed, 7 Feb 2007 17:29:40 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id E2792E1C93; Wed, 7 Feb 2007 18:28:54 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 4OVi1UOsEhaO; Wed, 7 Feb 2007 18:28:54 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 89EE7F5943; Wed, 7 Feb 2007 18:28:54 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l17HT75s000440; Wed, 7 Feb 2007 18:29:07 +0100 Date: Wed, 7 Feb 2007 17:29:02 +0000 (GMT) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. In-Reply-To: <20070208.012216.103777705.anemo@mba.ocn.ne.jp> Message-ID: References: <20070207.133809.71085888.nemoto@toshiba-tops.co.jp> <20070207110929.GA17660@linux-mips.org> <20070208.012216.103777705.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2533/Wed Feb 7 15:20:47 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13960 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007, Atsushi Nemoto wrote: > If the format of FCSR was common to all CPU (I hope so), we can do > check it in caller of fp_restore_context(), in C language. The R3010, etc. use bits 23 and 17:0 the same way as the R4000 and MIPS architecture processors do. The other bits are unused and hardwired to zeroes. Maciej From sshtylyov@ru.mvista.com Wed Feb 7 17:39:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 17:39:47 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:49035 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039488AbXBGRjm (ORCPT ); Wed, 7 Feb 2007 17:39:42 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 4DA8A3EC9; Wed, 7 Feb 2007 09:39:09 -0800 (PST) From: Sergei Shtylyov To: ralf@linux-mips.org Subject: [PATCH] (2.6.20) Toshiba JMR3927 and RBTX49x7 do support LE Date: Wed, 7 Feb 2007 20:39:05 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Organization: MontaVista Software Inc. Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Message-Id: <200702072039.05901.sshtylyov@ru.mvista.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13961 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Toshiba JMR3927 (RBHMA3100) and RBTX49[23]7 (RBHMA4[24]00) do support both little and big endian mode (if you flash the right PMON). Signed-off-by: Sergei Shtylyov Index: linux-2.6/arch/mips/Kconfig =================================================================== --- linux-2.6.orig/arch/mips/Kconfig +++ linux-2.6/arch/mips/Kconfig @@ -747,6 +747,7 @@ config TOSHIBA_JMR3927 select SWAP_IO_SPACE select SYS_HAS_CPU_TX39XX select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS @@ -761,6 +762,7 @@ config TOSHIBA_RBTX4927 select SYS_HAS_CPU_TX49XX select SYS_SUPPORTS_32BIT_KERNEL select SYS_SUPPORTS_64BIT_KERNEL + select SYS_SUPPORTS_LITTLE_ENDIAN select SYS_SUPPORTS_BIG_ENDIAN select TOSHIBA_BOARDS select GENERIC_HARDIRQS_NO__DO_IRQ From sshtylyov@ru.mvista.com Wed Feb 7 17:42:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 17:42:15 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:53899 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039489AbXBGRmL (ORCPT ); Wed, 7 Feb 2007 17:42:11 +0000 Received: from wasted.dev.rtsoft.ru (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 230CC3EC9; Wed, 7 Feb 2007 09:41:38 -0800 (PST) From: Sergei Shtylyov To: ralf@linux-mips.org Subject: [PATCH] (2.6.20) Toshiba RBTX49x7: declare prom_getcmdline() Date: Wed, 7 Feb 2007 20:41:36 +0300 User-Agent: KMail/1.5 Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Disposition: inline Organization: MontaVista Software Inc. Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200702072041.36064.sshtylyov@ru.mvista.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13962 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Fix a bunch of warnings caused by a missing prom_getcmdline() prototype. Signed-off-by: Sergei Shtylyov Index: linux-2.6/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c =================================================================== --- linux-2.6.orig/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c +++ linux-2.6/arch/mips/tx4927/toshiba_rbtx4927/toshiba_rbtx4927_setup.c @@ -137,6 +137,8 @@ int tx4927_using_backplane = 0; extern void gt64120_time_init(void); extern void toshiba_rbtx4927_irq_setup(void); +char *prom_getcmdline(void); + #ifdef CONFIG_PCI #define CONFIG_TX4927BUG_WORKAROUND #undef TX4927_SUPPORT_COMMAND_IO From sshtylyov@ru.mvista.com Wed Feb 7 17:55:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 17:55:14 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:6028 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039489AbXBGRzK (ORCPT ); Wed, 7 Feb 2007 17:55:10 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id D7A363EC9; Wed, 7 Feb 2007 09:54:37 -0800 (PST) Message-ID: <45CA125B.6050701@ru.mvista.com> Date: Wed, 07 Feb 2007 20:54:35 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Marc St-Jean Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master References: <45C77B61.1080209@pmc-sierra.com> In-Reply-To: <45C77B61.1080209@pmc-sierra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13963 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Marc St-Jean wrote: > Third attempt at the serial driver patch for the PMC-Sierra MSP71xx device. > > There are three different fixes: > 1. Fix for DesignWare THRE errata > - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" > tree also fixes it. This patch needs to be applied on top of it. > > 2. Fix for Busy Detect on LCR write > - Dropped the addition of UPIO_DWAPB iotype to 8250_early.c as Sergei > pointed out the fix wasn't complete and we don't require it. > > 3. Workaround for interrupt/data concurrency issue > - Fix must remain serial8250_interrupt() in order to mark interrupt as > handled. > > Thanks, > Marc > > Signed-off-by: Marc St-Jean > > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c > index 3d91bfc..489ff2b 100644 > --- a/drivers/serial/8250.c > +++ b/drivers/serial/8250.c > @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar > return inb(up->port.iobase + 1); > > case UPIO_MEM: > + case UPIO_DWAPB: > return readb(up->port.membase + offset); > > case UPIO_MEM32: > @@ -333,6 +334,8 @@ #endif > static void > serial_out(struct uart_8250_port *up, int offset, int value) > { > + /* Save the offset before it's remapped */ > + int save_offset = offset; > offset = map_8250_out_reg(up, offset) << up->port.regshift; > > switch (up->port.iotype) { > @@ -359,6 +362,18 @@ #endif > writeb(value, up->port.membase + offset); > break; > > + case UPIO_DWAPB: > + /* Save the LCR value so it can be re-written when a > + * Busy Detect interrupt occurs. */ > + if (save_offset == UART_LCR) > + up->lcr = value; > + writeb(value, up->port.membase + offset); > + /* Read the IER to ensure any interrupt is cleared before > + * returning from ISR. */ > + if ((save_offset == UART_TX || save_offset == UART_IER) && in_irq()) > + value = serial_in(up, UART_IER); > + break; > + > default: > outb(value, up->port.iobase + offset); > } > @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u > #ifdef CONFIG_SERIAL_8250_AU1X00 > case UPIO_AU: > #endif > + case UPIO_DWAPB: > serial_out(up, offset, value); > (void)serial_in(up, UART_LCR); /* safe, no side-effects */ > break; > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( > handled = 1; > > end = NULL; > + } else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY && > + up->port.iotype == UPIO_DWAPB) { Makes sense to swap the checks, i.e. to only test for UART_IIR_BUSY is this is UPIO_DWAPB. > + /* The DesignWare APB UART has an Busy Detect (0x07) > + * interrupt meaning an LCR write attempt occured while the > + * UART was busy. The interrupt must be cleared by reading > + * the UART status register (USR) and the LCR re-written. */ > + unsigned int status; > + status = *(volatile u32 *)up->port.data; > + serial_out(up, UART_LCR, up->lcr); > + > + handled = 1; > + > + end = NULL; > } else if (end == NULL) > end = l; [...] > @@ -2454,9 +2485,12 @@ int __init serial8250_start_console(stru > > add_preferred_console("ttyS", line, options); > printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", > - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", > - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : > - (unsigned long) port->iobase, options); > + line, > + (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB) > + ? "MMIO" : "I/O port", > + (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB) > + ? (unsigned long) port->mapbase : (unsigned long) port->iobase, > + options); Please turn this check into port->iotype >= UPIO_MEM, since this would be the Right Thing (RM). All iotypes beyond UPIO_MEM are memory mapped. And I thought I fixed that -- was wrong, obviously... :-/ > diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h > index 3c8a6aa..b3550cc 100644 > --- a/include/linux/serial_reg.h > +++ b/include/linux/serial_reg.h > @@ -37,6 +37,7 @@ #define UART_IIR_MSI 0x00 /* Modem stat > #define UART_IIR_THRI 0x02 /* Transmitter holding register empty */ > #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ > #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ > +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ Alan already said about this one... :-) BTW, your patches are still corrupt by your mailer (space added to lines starting with space) MBR, Sergei From laurentp@wp.pl Wed Feb 7 18:05:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 18:05:11 +0000 (GMT) Received: from mx5.wp.pl ([212.77.101.9]:15005 "EHLO mx1.wp.pl") by ftp.linux-mips.org with ESMTP id S20039501AbXBGSFG (ORCPT ); Wed, 7 Feb 2007 18:05:06 +0000 Received: (wp-smtpd smtp.wp.pl 16732 invoked from network); 7 Feb 2007 19:03:59 +0100 Received: from apn-239-193.gprsbal.plusgsm.pl (HELO [87.251.239.193]) (laurentp@[87.251.239.193]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 7 Feb 2007 19:03:59 +0100 Message-ID: <45CA1552.3080100@wp.pl> Date: Wed, 07 Feb 2007 19:07:14 +0100 From: "W.P." User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: pl, en, en-us MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Advice needed. References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> <45C3BB23.2070309@wp.pl> <50812.201.230.45.190.1170482268.squirrel@www.amilda.org> <45C45DDA.1000805@wp.pl> <24895.201.240.249.124.1170686083.squirrel@www.amilda.org> In-Reply-To: <24895.201.240.249.124.1170686083.squirrel@www.amilda.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13964 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: laurentp@wp.pl Precedence: bulk X-list: linux-mips >The configuration structure is difficult to understand (even if you have >the C header containing the struct) > > I don't have any header files for flash. Do you? In tarballs for BR, there is no source for utilities like flash. I'm trying to "decode" this structure, variable-by-variable. I have used your flash utility source >Just use the "flash" program. > > The one, that comes with original firmware? But what about webs, as i looked into, this needs too some knowledge of flash datastructures.? About webs -> will try to add some printf for debugging, and see. BTW, maybe the JP3 connector (just 12 little holes) is the JTAG. Will upload photo i think tomorrow. I have checked this with ohmometer and pin-map of 8186, and it seems to be JTAG + RESET+ something(?). You have published schema of JTAG cable, but what software shall anyone use? W.Piotrzkowski. From ralf@linux-mips.org Wed Feb 7 18:53:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 18:53:03 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:47551 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039514AbXBGSxB (ORCPT ); Wed, 7 Feb 2007 18:53:01 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l17Ir1gt028838; Wed, 7 Feb 2007 18:53:01 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l17IqxHt028837; Wed, 7 Feb 2007 18:52:59 GMT Date: Wed, 7 Feb 2007 18:52:59 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] (2.6.20) Toshiba JMR3927 and RBTX49x7 do support LE Message-ID: <20070207185259.GA25720@linux-mips.org> References: <200702072039.05901.sshtylyov@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702072039.05901.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13965 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 07, 2007 at 08:39:05PM +0300, Sergei Shtylyov wrote: > Toshiba JMR3927 (RBHMA3100) and RBTX49[23]7 (RBHMA4[24]00) do support both > little and big endian mode (if you flash the right PMON). Applied. Thanks, Ralf From ralf@linux-mips.org Wed Feb 7 18:53:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 18:53:28 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:50111 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039511AbXBGSxX (ORCPT ); Wed, 7 Feb 2007 18:53:23 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l17IrNxY028857; Wed, 7 Feb 2007 18:53:23 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l17IrNUs028856; Wed, 7 Feb 2007 18:53:23 GMT Date: Wed, 7 Feb 2007 18:53:23 +0000 From: Ralf Baechle To: Sergei Shtylyov Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] (2.6.20) Toshiba RBTX49x7: declare prom_getcmdline() Message-ID: <20070207185323.GB25720@linux-mips.org> References: <200702072041.36064.sshtylyov@ru.mvista.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200702072041.36064.sshtylyov@ru.mvista.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13966 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 07, 2007 at 08:41:36PM +0300, Sergei Shtylyov wrote: > Fix a bunch of warnings caused by a missing prom_getcmdline() prototype. Applied. Thanks, Ralf From Marc_St-Jean@pmc-sierra.com Wed Feb 7 20:52:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 20:52:41 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:33751 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039492AbXBGUwf (ORCPT ); Wed, 7 Feb 2007 20:52:35 +0000 Received: (qmail 28346 invoked by uid 101); 7 Feb 2007 20:51:03 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by father.pmc-sierra.com with SMTP; 7 Feb 2007 20:51:03 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l17Kp16g010424; Wed, 7 Feb 2007 12:51:02 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7R9B4>; Wed, 7 Feb 2007 12:51:01 -0800 Message-ID: <45CA3BAF.8070905@pmc-sierra.com> From: Marc St-Jean To: Sergei Shtylyov Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Wed, 7 Feb 2007 12:50:55 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 07 Feb 2007 20:50:56.0183 (UTC) FILETIME=[A9F16470:01C74AF9] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13967 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Sergei Shtylyov wrote: > Marc St-Jean wrote: > > Third attempt at the serial driver patch for the PMC-Sierra MSP71xx > device. > > > > There are three different fixes: > > 1. Fix for DesignWare THRE errata > > - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" > > tree also fixes it. This patch needs to be applied on top of it. > > > > 2. Fix for Busy Detect on LCR write > > - Dropped the addition of UPIO_DWAPB iotype to 8250_early.c as Sergei > > pointed out the fix wasn't complete and we don't require it. > > > > 3. Workaround for interrupt/data concurrency issue > > - Fix must remain serial8250_interrupt() in order to mark interrupt as > > handled. > > > > Thanks, > > Marc > > > > Signed-off-by: Marc St-Jean > > > > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c ... > > break; > > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( > > handled = 1; > > > > end = NULL; > > + } else if ((iir & UART_IIR_BUSY) == UART_IIR_BUSY && > > + up->port.iotype == UPIO_DWAPB) { > > Makes sense to swap the checks, i.e. to only test for UART_IIR_BUSY is > this is UPIO_DWAPB. I had left in the other order for readability with the previous test. I agree this will save a few cycles so I've reordered. > [...] > > > @@ -2454,9 +2485,12 @@ int __init serial8250_start_console(stru > > > > add_preferred_console("ttyS", line, options); > > printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", > > - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", > > - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : > > - (unsigned long) port->iobase, options); > > + line, > > + (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB) > > + ? "MMIO" : "I/O port", > > + (port->iotype == UPIO_MEM || port->iotype == UPIO_DWAPB) > > + ? (unsigned long) port->mapbase : (unsigned > long) port->iobase, > > + options); > > Please turn this check into port->iotype >= UPIO_MEM, since this > would be > the Right Thing (RM). All iotypes beyond UPIO_MEM are memory mapped. > And I > thought I fixed that -- was wrong, obviously... :-/ This is news to me, I thought the numbering was of no particular importance. I've made the change. > > diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h > > index 3c8a6aa..b3550cc 100644 > > --- a/include/linux/serial_reg.h > > +++ b/include/linux/serial_reg.h > > @@ -37,6 +37,7 @@ #define UART_IIR_MSI 0x00 /* Modem stat > > #define UART_IIR_THRI 0x02 /* Transmitter holding > register empty */ > > #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ > > #define UART_IIR_RLSI 0x06 /* Receiver line status > interrupt */ > > +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy > Detect */ > > Alan already said about this one... :-) Yes, changed. > BTW, your patches are still corrupt by your mailer (space added to > lines > starting with space) Argh! There were no spaces in the message window before sending, I swear! I've solved the problem for the next patch. Marc From Marc_St-Jean@pmc-sierra.com Wed Feb 7 22:36:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 07 Feb 2007 22:36:32 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:9361 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039529AbXBGWg1 (ORCPT ); Wed, 7 Feb 2007 22:36:27 +0000 Received: (qmail 12366 invoked by uid 101); 7 Feb 2007 22:35:17 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by mother.pmc-sierra.com with SMTP; 7 Feb 2007 22:35:17 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l17MZ6F8018753; Wed, 7 Feb 2007 14:35:15 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7SBZX>; Wed, 7 Feb 2007 14:35:06 -0800 Message-ID: <45CA5415.4000402@pmc-sierra.com> From: Marc St-Jean To: linux-serial@vger.kernel.org Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Date: Wed, 7 Feb 2007 14:35:01 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 07 Feb 2007 22:35:02.0368 (UTC) FILETIME=[34F59600:01C74B08] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13968 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx device. There are three different fixes: 1. Fix for DesignWare THRE errata - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" tree also fixes it. This patch needs to be applied on top of "mm" patch. 2. Fix for Busy Detect on LCR write - Changed the ordering of test in serial8250_interrupt(). - Combined test for UPIO_DWAPB with UPIO_MEM in serial8250_start_console(). - Renamed new uart_8250_port member to private_data. 3. Workaround for interrupt/data concurrency issue - No changes since last patch. Thanks, Marc Signed-off-by: Marc St-Jean diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 3d91bfc..b309c4c 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar return inb(up->port.iobase + 1); case UPIO_MEM: + case UPIO_DWAPB: return readb(up->port.membase + offset); case UPIO_MEM32: @@ -333,6 +334,8 @@ #endif static void serial_out(struct uart_8250_port *up, int offset, int value) { + /* Save the offset before it's remapped */ + int save_offset = offset; offset = map_8250_out_reg(up, offset) << up->port.regshift; switch (up->port.iotype) { @@ -359,6 +362,18 @@ #endif writeb(value, up->port.membase + offset); break; + case UPIO_DWAPB: + /* Save the LCR value so it can be re-written when a + * Busy Detect interrupt occurs. */ + if (save_offset == UART_LCR) + up->lcr = value; + writeb(value, up->port.membase + offset); + /* Read the IER to ensure any interrupt is cleared before + * returning from ISR. */ + if ((save_offset == UART_TX || save_offset == UART_IER) && in_irq()) + value = serial_in(up, UART_IER); + break; + default: outb(value, up->port.iobase + offset); } @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u #ifdef CONFIG_SERIAL_8250_AU1X00 case UPIO_AU: #endif + case UPIO_DWAPB: serial_out(up, offset, value); (void)serial_in(up, UART_LCR); /* safe, no side-effects */ break; @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( handled = 1; end = NULL; + } else if (up->port.iotype == UPIO_DWAPB && + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { + /* The DesignWare APB UART has an Busy Detect (0x07) + * interrupt meaning an LCR write attempt occured while the + * UART was busy. The interrupt must be cleared by reading + * the UART status register (USR) and the LCR re-written. */ + unsigned int status; + status = *(volatile u32 *)up->port.private_data; + serial_out(up, UART_LCR, up->lcr); + + handled = 1; + + end = NULL; } else if (end == NULL) end = l; @@ -2085,6 +2114,7 @@ static int serial8250_request_std_resour case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2122,6 +2152,7 @@ static void serial8250_release_std_resou case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2454,8 +2485,8 @@ int __init serial8250_start_console(stru add_preferred_console("ttyS", line, options); printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : + line, port->iotype >= UPIO_MEM ? "MMIO" : "I/O port", + port->iotype >= UPIO_MEM ? (unsigned long) port->mapbase : (unsigned long) port->iobase, options); if (!(serial8250_console.flags & CON_ENABLED)) { serial8250_console.flags &= ~CON_PRINTBUFFER; diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c index f84982e..f5b6036 100644 --- a/drivers/serial/serial_core.c +++ b/drivers/serial/serial_core.c @@ -2057,6 +2057,7 @@ uart_report_port(struct uart_driver *drv case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: snprintf(address, sizeof(address), "MMIO 0x%lx", port->mapbase); break; @@ -2401,6 +2402,7 @@ int uart_match_port(struct uart_port *po case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: return (port1->mapbase == port2->mapbase); } return 0; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index cf23813..bd9711a 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -230,6 +230,7 @@ #define UPIO_MEM (2) #define UPIO_MEM32 (3) #define UPIO_AU (4) /* Au1x00 type IO */ #define UPIO_TSI (5) /* Tsi108/109 type IO */ +#define UPIO_DWAPB (6) /* DesignWare APB UART */ unsigned int read_status_mask; /* driver specific */ unsigned int ignore_status_mask; /* driver specific */ @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( struct device *dev; /* parent device */ unsigned char hub6; /* this should be in the 8250 driver */ unsigned char unused[3]; + void *private_data; /* generic platform data pointer */ }; /* diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 3c8a6aa..1c5ed7d 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -38,6 +38,8 @@ #define UART_IIR_THRI 0x02 /* Transmitt #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ + #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ From thomas.koeller@baslerweb.com Thu Feb 8 01:11:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 01:11:48 +0000 (GMT) Received: from mail02.hansenet.de ([213.191.73.62]:55478 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20039565AbXBHBLn (ORCPT ); Thu, 8 Feb 2007 01:11:43 +0000 Received: from [213.39.208.75] (213.39.208.75) by webmail.hansenet.de (7.2.074) (authenticated as mbx20228207@koeller-hh.org) id 45BEA1BF003D1686; Thu, 8 Feb 2007 02:07:53 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id A787D479FC; Thu, 8 Feb 2007 02:07:51 +0100 (CET) From: Thomas Koeller Date: Thu, 8 Feb 2007 01:57:25 +0100 Subject: [PATCH] eXcite nand flash driver X-Length: 10171 X-UID: 5 To: linux-mtd@lists.infradead.org Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200702080157.25432.thomas.koeller@baslerweb.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13969 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips This is a nand flash driver for the eXcite series of intelligent cameras manufactured by Basler Vision Technologies AG. Signed-off-by: Thomas Koeller =2D-- drivers/mtd/nand/Kconfig | 18 +++- drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/excite_nandflash.c | 259=20 +++++++++++++++++++++++++++++++++++ 3 files changed, 277 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 358f55a..5b50396 100644 =2D-- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -216,10 +216,26 @@ config MTD_NAND_DISKONCHIP_BBTWRITE Even if you leave this disabled, you can enable BBT writes at module load time (assuming you build diskonchip as a module) with the module parameter "inftl_bbt_write=3D1". =2D + =20 config MTD_NAND_SHARPSL tristate "Support for NAND Flash on Sharp SL Series (C7xx + others)" depends on MTD_NAND && ARCH_PXA +=20 +config MTD_NAND_BASLER_EXCITE + tristate "Support for NAND Flash on Basler eXcite" + depends on MTD_NAND && BASLER_EXCITE + help + This enables the driver for the NAND flash device found on the + Basler eXcite Smart Camera. If built as a module, the driver + will be named "excite_nandflash.ko". + +config MTD_NAND_BASLER_EXCITE + tristate "Support for NAND Flash on Basler eXcite" + depends on MTD_NAND && BASLER_EXCITE + help + This enables the driver for the NAND flash device found on the + Basler eXcite Smart Camera. If built as a module, the driver + will be named "excite_nandflash.ko". =20 config MTD_NAND_CAFE tristate "NAND support for OLPC CAF=C9 chip" diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index f7a53f0..80f1dfc 100644 =2D-- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_MTD_NAND_NANDSIM) +=3D nands obj-$(CONFIG_MTD_NAND_CS553X) +=3D cs553x_nand.o obj-$(CONFIG_MTD_NAND_NDFC) +=3D ndfc.o obj-$(CONFIG_MTD_NAND_AT91) +=3D at91_nand.o +obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) +=3D excite_nandflash.o =20 nand-objs :=3D nand_base.o nand_bbt.o cafe_nand-objs :=3D cafe.o cafe_ecc.o diff --git a/drivers/mtd/nand/excite_nandflash.c=20 b/drivers/mtd/nand/excite_nandflash.c new file mode 100644 index 0000000..d683659 =2D-- /dev/null +++ b/drivers/mtd/nand/excite_nandflash.c @@ -0,0 +1,259 @@ +/* +* Copyright (C) 2005 - 2007 by Basler Vision Technologies AG +* Author: Thomas Koeller +* Original code by Thies Moeller +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 U= SA +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include + +#include + +#define EXCITE_NANDFLASH_VERSION "0.1" + +/* I/O register offsets */ +#define EXCITE_NANDFLASH_DATA_BYTE 0x00 +#define EXCITE_NANDFLASH_STATUS_BYTE 0x0c +#define EXCITE_NANDFLASH_ADDR_BYTE 0x10 +#define EXCITE_NANDFLASH_CMD_BYTE 0x14 + +#define io_readb(__a__) __raw_readb((__a__)) +#define io_writeb(__v__, __a__) __raw_writeb((__v__), (__a__)) + +typedef void __iomem *io_reg_t; + +/* prefix for debug output */ +static const char module_id[] =3D "excite_nandflash"; + +/* + * partition definition + */ +static const struct mtd_partition partition_info[] =3D { + { + .name =3D "eXcite RootFS", + .offset =3D 0, + .size =3D MTDPART_SIZ_FULL + } +}; + +static inline const struct resource *excite_nand_get_resource + (struct platform_device *d, unsigned long flags, const char *basename)= { + const char fmt[] =3D "%s_%u"; + char buf[80]; + + if (unlikely + (snprintf(buf, sizeof buf, fmt, basename, d->id) >=3D sizeof buf)) + return NULL; + return platform_get_resource_byname(d, flags, buf); +} + +static inline io_reg_t +excite_nand_map_regs(struct platform_device *d, const char *basename) +{ + void *result =3D NULL; + const struct resource *const r =3D + excite_nand_get_resource(d, IORESOURCE_MEM, basename); + if (likely(r)) + result =3D ioremap_nocache(r->start, r->end + 1 - r->start); + return result; +} + +/* controller and mtd information */ +struct excite_nand_drvdata { + struct mtd_info board_mtd; + struct nand_chip board_chip; + io_reg_t regs; +}; + +/* command and control functions */ +static void excite_nand_control(struct mtd_info *mtd, int cmd, + unsigned int ctrl) +{ + io_reg_t regs =3D + container_of(mtd, struct excite_nand_drvdata, board_mtd)->regs; + static void __iomem *tgt =3D NULL; + + switch (ctrl) { + case NAND_CTRL_CHANGE | NAND_CTRL_CLE: + tgt =3D regs + EXCITE_NANDFLASH_CMD_BYTE; + break; + case NAND_CTRL_CHANGE | NAND_CTRL_ALE: + tgt =3D regs + EXCITE_NANDFLASH_ADDR_BYTE; + break; + case NAND_CTRL_CHANGE | NAND_NCE: + tgt =3D regs + EXCITE_NANDFLASH_DATA_BYTE; + break; + } + + if (cmd !=3D NAND_CMD_NONE) + io_writeb(cmd, tgt); +} + +/* excite_nand_devready() + * + * returns 0 if the nand is busy, 1 if it is ready + */ +static int excite_nand_devready(struct mtd_info *mtd) +{ + struct excite_nand_drvdata * const drvdata =3D + container_of(mtd, struct excite_nand_drvdata, board_mtd); + return io_readb(drvdata->regs + EXCITE_NANDFLASH_STATUS_BYTE); +} + +/* excite_nand_remove + * + * called by device layer to remove the driver + * the binding to the mtd and all allocated + * resources are released + */ +static int __exit excite_nand_remove(struct device *dev) +{ + struct excite_nand_drvdata * const this =3D dev_get_drvdata(dev); + + dev_set_drvdata(dev, NULL); + + if (unlikely(!this)) { + printk(KERN_ERR "%s: called %s without private data!!", + module_id, __func__); + return -EINVAL; + } + + /* first thing we need to do is release our mtd + * then go through freeing the resource used + */ + nand_release(&this->board_mtd); + + /* free the common resources */ + if (likely(this->regs)) { + iounmap(this->regs); + this->regs =3D NULL; + } + + kfree(this); + + DEBUG(MTD_DEBUG_LEVEL1, "%s: removed\n", module_id); + return 0; +} + +/* excite_nand_probe + * + * called by device layer when it finds a device matching + * one our driver can handled. This code checks to see if + * it can allocate all necessary resources then calls the + * nand layer to look for devices +*/ +static int __init excite_nand_probe(struct device *dev) +{ + struct platform_device * const pdev =3D to_platform_device(dev); + + struct excite_nand_drvdata *drvdata; /* private driver data */ + struct nand_chip *board_chip; /* private flash chip data */ + struct mtd_info *board_mtd; /* mtd info for this board */ + int scan_res; + + drvdata =3D kzalloc(sizeof(*drvdata), GFP_KERNEL); + if (unlikely(!drvdata)) { + printk(KERN_ERR "%s: no memory for drvdata\n", + module_id); + return -ENOMEM; + } + + /* bind private data into driver */ + dev_set_drvdata(dev, drvdata); + + /* allocate and map the resource */ + drvdata->regs =3D + excite_nand_map_regs(pdev, EXCITE_NANDFLASH_RESOURCE_REGS); + + if (unlikely(!drvdata->regs)) { + printk(KERN_ERR "%s: cannot reserve register region\n", + module_id); + kfree(drvdata); + return -ENXIO; + } + + /* initialise our chip */ + board_chip =3D &drvdata->board_chip; + board_chip->IO_ADDR_R =3D board_chip->IO_ADDR_W =3D + drvdata->regs + EXCITE_NANDFLASH_DATA_BYTE; + board_chip->cmd_ctrl =3D excite_nand_control; + board_chip->dev_ready =3D excite_nand_devready; + board_chip->chip_delay =3D 25; + board_chip->ecc.mode =3D NAND_ECC_SOFT; + + /* link chip to mtd */ + board_mtd =3D &drvdata->board_mtd; + board_mtd->priv =3D board_chip; + + DEBUG(MTD_DEBUG_LEVEL2, "%s: device scan\n", module_id); + scan_res =3D nand_scan(&drvdata->board_mtd, 1); + + if (likely(!scan_res)) { + DEBUG(MTD_DEBUG_LEVEL2, "%s: register partitions\n", module_id); + add_mtd_partitions(&drvdata->board_mtd, partition_info, + sizeof partition_info / sizeof partition_info[0]); + } else { + iounmap(drvdata->regs); + kfree(drvdata); + printk(KERN_ERR "%s: device scan failed\n", module_id); + return -EIO; + } + return 0; +} + +static struct device_driver excite_nand_driver =3D { + .name =3D "excite_nand", + .bus =3D &platform_bus_type, + .probe =3D excite_nand_probe, + .remove =3D __exit_p(excite_nand_remove) +}; + +static int __init excite_nand_init(void) +{ + pr_info("Basler eXcite nand flash driver Version " + EXCITE_NANDFLASH_VERSION "\n"); + return driver_register(&excite_nand_driver); +} + +static void __exit excite_nand_exit(void) +{ + driver_unregister(&excite_nand_driver); +} + +module_init(excite_nand_init); +module_exit(excite_nand_exit); + +MODULE_AUTHOR("Thomas Koeller "); +MODULE_DESCRIPTION("Basler eXcite NAND-Flash driver"); +MODULE_LICENSE("GPL"); +MODULE_VERSION(EXCITE_NANDFLASH_VERSION) =2D-=20 1.4.3 From yoichi_yuasa@tripeaks.co.jp Thu Feb 8 01:31:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 01:31:54 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:65075 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20039579AbXBHBbt (ORCPT ); Thu, 8 Feb 2007 01:31:49 +0000 Received: by mo.po.2iij.net (mo31) id l181UVJt038414; Thu, 8 Feb 2007 10:30:31 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox33) id l181UTme065810 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Thu, 8 Feb 2007 10:30:29 +0900 (JST) Date: Thu, 8 Feb 2007 10:30:29 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] removed needless #include on emma2rh Message-Id: <20070208103029.40481af6.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13970 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips Hi Ralf, These irq.c don't need #include . Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/emma2rh/common/irq.c mips/arch/mips/emma2rh/common/irq.c --- mips-orig/arch/mips/emma2rh/common/irq.c 2007-02-07 18:24:06.864096500 +0900 +++ mips/arch/mips/emma2rh/common/irq.c 2007-02-08 09:42:27.348211000 +0900 @@ -27,7 +27,6 @@ #include #include -#include #include #include #include diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/emma2rh/markeins/irq.c mips/arch/mips/emma2rh/markeins/irq.c --- mips-orig/arch/mips/emma2rh/markeins/irq.c 2007-02-07 18:24:06.876097250 +0900 +++ mips/arch/mips/emma2rh/markeins/irq.c 2007-02-08 09:42:46.117384000 +0900 @@ -29,7 +29,6 @@ #include #include -#include #include #include #include From anemo@mba.ocn.ne.jp Thu Feb 8 03:02:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 03:03:02 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:10684 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039596AbXBHDC5 (ORCPT ); Thu, 8 Feb 2007 03:02:57 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Thu, 8 Feb 2007 12:02:55 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 9CB4741E7F; Thu, 8 Feb 2007 12:02:19 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 8FF3141E7E; Thu, 8 Feb 2007 12:02:19 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l1832JW0067497; Thu, 8 Feb 2007 12:02:19 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Thu, 08 Feb 2007 12:02:19 +0900 (JST) Message-Id: <20070208.120219.96684712.nemoto@toshiba-tops.co.jp> To: macro@linux-mips.org Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: References: <20070207110929.GA17660@linux-mips.org> <20070208.012216.103777705.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13971 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 7 Feb 2007 17:29:02 +0000 (GMT), "Maciej W. Rozycki" wrote: > > If the format of FCSR was common to all CPU (I hope so), we can do > > check it in caller of fp_restore_context(), in C language. > > The R3010, etc. use bits 23 and 17:0 the same way as the R4000 and MIPS > architecture processors do. The other bits are unused and hardwired to > zeroes. So we can do it in C, but it will conflicts with Franck's signal cleanup patchset. I hope his patchset applied first. Also I wonder SIGSEGV is correct behavior on this case. SIGFPE? --- Atsushi Nemoto From Eckhardt@satorlaser.com Thu Feb 8 08:20:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 08:20:45 +0000 (GMT) Received: from mail.domino-uk.com ([193.131.116.193]:44561 "EHLO UK-HC-PS1.domino-printing.com") by ftp.linux-mips.org with ESMTP id S20037844AbXBHIUl convert rfc822-to-8bit (ORCPT ); Thu, 8 Feb 2007 08:20:41 +0000 Received: from emea-exchange3.emea.dps.local (EMEA-EXCHANGE3) by UK-HC-PS1.domino-printing.com (Clearswift SMTPRS 5.2.5) with ESMTP id for ; Thu, 8 Feb 2007 08:22:05 +0000 Received: from tuxator2.emea.dps.local ([192.168.55.75]) by emea-exchange3.emea.dps.local with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 09:22:04 +0100 From: Ulrich Eckhardt Organization: Sator Laser GmbH To: linux-mips@linux-mips.org Subject: Re: [PATCH] eXcite nand flash driver Date: Thu, 8 Feb 2007 09:20:12 +0100 User-Agent: KMail/1.9.5 References: <200702080157.25432.thomas.koeller@baslerweb.com> In-Reply-To: <200702080157.25432.thomas.koeller@baslerweb.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200702080920.12723.eckhardt@satorlaser.com> X-OriginalArrivalTime: 08 Feb 2007 08:22:04.0500 (UTC) FILETIME=[36FC6940:01C74B5A] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13972 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: eckhardt@satorlaser.com Precedence: bulk X-list: linux-mips Just some cosmetic notes ... On Thursday 08 February 2007 01:57, Thomas Koeller wrote: > @@ -216,10 +216,26 @@ config MTD_NAND_DISKONCHIP_BBTWRITE > Even if you leave this disabled, you can enable BBT writes at module > load time (assuming you build diskonchip as a module) with the module > parameter "inftl_bbt_write=1". > - > + This just inserts whitespace. > tristate "NAND support for OLPC CAFÉ chip" The accent on the E might cause problems, but I'm not sure. > +#define io_readb(__a__) __raw_readb((__a__)) > +#define io_writeb(__v__, __a__) __raw_writeb((__v__), (__a__)) I would have used an inline function. Also, aren't there functions to use IOs already? What's the reason here? > +/* prefix for debug output */ > +static const char module_id[] = "excite_nandflash"; I'd have used static const char* module_id = "excite_nandflash"; except if you need the sizeof it to capture the length. > +static inline const struct resource *excite_nand_get_resource > + (struct platform_device *d, unsigned long flags, const char *basename){ > + const char fmt[] = "%s_%u"; Here, too, is no need for a local buffer, just use a pointer. > +/* excite_nand_probe > + * > + * called by device layer when it finds a device matching > + * one our driver can handled. [...] "... when it finds a device our driver can handle." Otherwise I'd say it looks very clean, better than quite some other stuff I have seen. Uli ************************************************************************************** Visit our website at ************************************************************************************** Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden. E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich. ************************************************************************************** From vagabon.xyz@gmail.com Thu Feb 8 08:54:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 08:54:25 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.237]:28223 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038340AbXBHIyU (ORCPT ); Thu, 8 Feb 2007 08:54:20 +0000 Received: by qb-out-0506.google.com with SMTP id e12so43244qba for ; Thu, 08 Feb 2007 00:53:18 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NvlNjizpA+1/Xe+yd+OqlNSA8H7z/25t25Fevyt3zgmVMz6jRodkctoLvJLWpCb1HFZv4zg7TNOw3jQ5/97c6+hCSXMxsTes3HGjl4tnzUG3eGbaXexVa/oVKRUCChH055yvEG0bg6hGW0pfNiqnYT+pRuNmAFKz07JVi7pjClg= Received: by 10.115.54.1 with SMTP id g1mr2466742wak.1170924798222; Thu, 08 Feb 2007 00:53:18 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 00:53:18 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 09:53:18 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 9/10] signal: do not use save_static_function() anymore Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070208.004049.51866970.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11706854683935-git-send-email-fbuihuu@gmail.com> <11706854703880-git-send-email-fbuihuu@gmail.com> <20070208.004049.51866970.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13973 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi Atsushi, On 2/7/07, Atsushi Nemoto wrote: > On Mon, 5 Feb 2007 15:24:27 +0100, Franck Bui-Huu wrote: > > For the sys_sigsuspend() case, I don't see any reasons... > > Maybe that was needed before commit > 7b3e2fc847c8325a7b35185fa1fc2f1729ed9c5b. At that time > sys_sigsuspend() called do_signal() (which includes > setup_sigcontext()) directly. So all registers must be saved to > kernel stack. > Well, I haven't look at the old code you pointed out. So I dunno, but I still really think we currently don't need to save/restore static registers at all... I tried the following patch: diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 229276a..046fb1b 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -68,7 +68,9 @@ int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) err |= __put_user(regs->cp0_epc, &sc->sc_pc); err |= __put_user(0, &sc->sc_regs[0]); - for (i = 1; i < 32; i++) + for (i = 1; i < 16; i++) + err |= __put_user(regs->regs[i], &sc->sc_regs[i]); + for (i = 24; i < 32; i++) err |= __put_user(regs->regs[i], &sc->sc_regs[i]); err |= __put_user(regs->hi, &sc->sc_mdhi); @@ -126,7 +128,9 @@ int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); } - for (i = 1; i < 32; i++) + for (i = 1; i < 16; i++) + err |= __get_user(regs->regs[i], &sc->sc_regs[i]); + for (i = 24; i < 32; i++) err |= __get_user(regs->regs[i], &sc->sc_regs[i]); err |= __get_user(used_math, &sc->sc_used_math); ...and it still passes LTP tests. Someone reported that not saving/restoring static registers may break user tools but the gain is important I think. If you interested, please take a look to the following thread: http://marc.theaimsgroup.com/?l=linux-mips&m=117032669701164&w=2 Thanks -- Franck From vagabon.xyz@gmail.com Thu Feb 8 08:56:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 08:56:26 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.232]:13898 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038340AbXBHI4W (ORCPT ); Thu, 8 Feb 2007 08:56:22 +0000 Received: by qb-out-0506.google.com with SMTP id a33so37153qbd for ; Thu, 08 Feb 2007 00:55:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=KCkcJZExjA5m9IEm0cGe+IMDrZsdnbxUOexOQYD7h0c5GrWEOajY+IdsYgsRd4nIG7hcKvHVRovCcz84KvZTOh0WVA7+7NZWJ6dFr4v5UDYagpntlN6afMa7Qm1BE2Dt/OYxhWzavR71jEPQm0MOAvDdSua3EfpjPzCps2YbmqU= Received: by 10.114.171.1 with SMTP id t1mr2466547wae.1170924920865; Thu, 08 Feb 2007 00:55:20 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 00:55:20 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 09:55:20 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 0/10] Clean up signal code [take #3] Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070208.010430.58789357.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11706854683935-git-send-email-fbuihuu@gmail.com> <20070208.010430.58789357.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13974 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi Atsushi Thanks for you review ! On 2/7/07, Atsushi Nemoto wrote: > # Though [PATCH 6/10] failed due to recent whitespace cleanup ... > I can rebase it if needed, > I hope this patchset applied before updating my fp_context patches. yeah I hope too... -- Franck From vagabon.xyz@gmail.com Thu Feb 8 09:18:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 09:18:05 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.235]:18562 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037872AbXBHJSB (ORCPT ); Thu, 8 Feb 2007 09:18:01 +0000 Received: by qb-out-0506.google.com with SMTP id e12so44798qba for ; Thu, 08 Feb 2007 01:17:00 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dygJ1HJOXEd98Hn6USdm8nRShXZa9tigDmZhqWFU+wTXApTed3hF0uyVu+Q9INRk51Njw7VdgYvR7I1By6lsFK+TlmZzE3ix8uuWnjBCFawc6dYFhThpOpRKsZesimxGCg4f+I0CdihFgQemDMyWAmQSOP4jUEQC6GJBpgVmjOw= Received: by 10.115.95.1 with SMTP id x1mr2508581wal.1170926219452; Thu, 08 Feb 2007 01:16:59 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 01:16:59 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 10:16:59 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 0/10] Clean up signal code [take #3] Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11706854683935-git-send-email-fbuihuu@gmail.com> <20070208.010430.58789357.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13975 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/8/07, Franck Bui-Huu wrote: > Hi Atsushi > > Thanks for you review ! > > On 2/7/07, Atsushi Nemoto wrote: > > # Though [PATCH 6/10] failed due to recent whitespace cleanup ... > > > > I can rebase it if needed, > > > I hope this patchset applied before updating my fp_context patches. > > yeah I hope too... > BTW, did you have time to try it on a 64-bits kernel ? Thanks -- Franck From thomas.koeller@baslerweb.com Thu Feb 8 10:23:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 10:23:42 +0000 (GMT) Received: from mail.baslerweb.com ([145.253.187.130]:18882 "EHLO mail.baslerweb.com") by ftp.linux-mips.org with ESMTP id S20038447AbXBHKXi convert rfc822-to-8bit (ORCPT ); Thu, 8 Feb 2007 10:23:38 +0000 Received: (from smtpd@127.0.0.1) by mail.baslerweb.com (8.13.4/8.13.4) id l18AKSOD021602; Thu, 8 Feb 2007 11:20:28 +0100 Received: from unknown [172.16.20.75] by gateway id /processing/kwEkM5s9; Thu Feb 08 11:20:27 2007 Received: from ahr040s.basler.corp ([172.16.20.40]) by AHR075S.basler.corp with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 11:20:27 +0100 From: Thomas Koeller Organization: Basler AG To: Ulrich Eckhardt Date: Thu, 8 Feb 2007 11:20:25 +0100 User-Agent: KMail/1.9.5 Cc: linux-mips@linux-mips.org References: <200702080157.25432.thomas.koeller@baslerweb.com> <200702080920.12723.eckhardt@satorlaser.com> In-Reply-To: <200702080920.12723.eckhardt@satorlaser.com> MIME-Version: 1.0 Message-Id: <200702081120.26026.thomas.koeller@baslerweb.com> X-OriginalArrivalTime: 08 Feb 2007 10:20:27.0140 (UTC) FILETIME=[C07D4440:01C74B6A] X-SecurE-Mail-Gateway: Version: 5.00.3.1 (smtpd: 6.53.8.7) Date: 20070208102028Z Subject: Re: [PATCH] eXcite nand flash driver Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13976 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips On Thursday 08 February 2007 09:20, Ulrich Eckhardt wrote: > Just some cosmetic notes ... > > On Thursday 08 February 2007 01:57, Thomas Koeller wrote: > > @@ -216,10 +216,26 @@ config MTD_NAND_DISKONCHIP_BBTWRITE > > Even if you leave this disabled, you can enable BBT writes at module > > load time (assuming you build diskonchip as a module) with the module > > parameter "inftl_bbt_write=1". > > - > > + > > This just inserts whitespace. No, it actually _removes_ whitspace. > > > tristate "NAND support for OLPC CAFÉ chip" > > The accent on the E might cause problems, but I'm not sure. This has been in there before. > > > +#define io_readb(__a__) __raw_readb((__a__)) > > +#define io_writeb(__v__, __a__) __raw_writeb((__v__), (__a__)) > > I would have used an inline function. Also, aren't there functions to use > IOs already? What's the reason here? > > > +/* prefix for debug output */ > > +static const char module_id[] = "excite_nandflash"; > > I'd have used > > static const char* module_id = "excite_nandflash"; > > except if you need the sizeof it to capture the length. Then I'd have used static const char * const module_id = "excite_nandflash"; but what is the advantage of doing so? > > > +static inline const struct resource *excite_nand_get_resource > > + (struct platform_device *d, unsigned long flags, const char > > *basename){ + const char fmt[] = "%s_%u"; > > Here, too, is no need for a local buffer, just use a pointer. > > > +/* excite_nand_probe > > + * > > + * called by device layer when it finds a device matching > > + * one our driver can handled. [...] > > "... when it finds a device our driver can handle." Right. > > Otherwise I'd say it looks very clean, better than quite some other stuff I > have seen. > > Uli > Thanks for your comments! _______________________________ Thomas Köller, Software Developer Basler Vision Technologies An der Strusbek 60-62 22926 Ahrensburg Germany Tel. +49 (0) 4102 - 463 390 Fax +49 (0) 4102 - 463 390 mailto:thomas.koeller@baslerweb.com http://www.baslerweb.com Vorstand: Dr.-Ing. Dietmar Ley (Vorsitzender) · John P. Jennings · Peter Krumhoff · Aufsichtsratsvorsitzender: Norbert Basler Basler AG · Amtsgericht Ahrensburg HRB 4090 · Ust-IdNr.: DE 135 098 121 · Steuer-Nr.: 30 292 04497 _______________________________ From Barry.Bridgman@raymarine.com Thu Feb 8 10:37:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 10:37:11 +0000 (GMT) Received: from mail3.raymarine.com ([213.206.137.1]:22388 "EHLO RMUKMAIL.raymarine.com") by ftp.linux-mips.org with ESMTP id S20038451AbXBHKhG convert rfc822-to-8bit (ORCPT ); Thu, 8 Feb 2007 10:37:06 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: Toshiba TX4939 Date: Thu, 8 Feb 2007 10:34:38 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [PATCH] eXcite nand flash driver Thread-Index: AcdLa3NGu/WpD2kdQq+3YlutiLL8rAAAF7+w From: "Barry Bridgman" To: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13977 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Barry.Bridgman@raymarine.com Precedence: bulk X-list: linux-mips Hi All First post on this list as I have come over from xscale and x86 embedded linux designs to a potential MIPS design. Does anyone know of any sources of information regarding linux on the TX4939 initially on the RBTX4939 development platform. Any info would be gratefully received. I have done some searching for info on the TX4939 but info seems thin on the ground. Many Thanks Barry From sshtylyov@ru.mvista.com Thu Feb 8 12:05:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 12:05:49 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:16554 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038507AbXBHMFo (ORCPT ); Thu, 8 Feb 2007 12:05:44 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id B4C7B3EC9; Thu, 8 Feb 2007 04:05:10 -0800 (PST) Message-ID: <45CB11F2.1070504@ru.mvista.com> Date: Thu, 08 Feb 2007 15:05:06 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Barry Bridgman Cc: linux-mips@linux-mips.org Subject: Re: Toshiba TX4939 References: In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13978 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Barry Bridgman wrote: > First post on this list as I have come over from xscale and x86 embedded linux designs to a potential MIPS design. > Does anyone know of any sources of information regarding linux on the TX4939 initially on the RBTX4939 development platform. MontaVista has released the 2.6.10 kernel for this board about a year ago. Unfortunately, it hasn't been pushed to Linux/MIPS. > Any info would be gratefully received. I have done some searching for info on the TX4939 but info seems thin on the ground. > Many Thanks > Barry WBR, Sergei From sshtylyov@ru.mvista.com Thu Feb 8 12:13:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 12:13:50 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:33450 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038521AbXBHMNq (ORCPT ); Thu, 8 Feb 2007 12:13:46 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 169B63EC9; Thu, 8 Feb 2007 04:13:12 -0800 (PST) Message-ID: <45CB13D5.3090907@ru.mvista.com> Date: Thu, 08 Feb 2007 15:13:09 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Marc St-Jean Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master References: <45CA5415.4000402@pmc-sierra.com> In-Reply-To: <45CA5415.4000402@pmc-sierra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13979 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Marc St-Jean wrote: > Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx device. > > There are three different fixes: > 1. Fix for DesignWare THRE errata > - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" > tree also fixes it. This patch needs to be applied on top of "mm" patch. > > 2. Fix for Busy Detect on LCR write > - Changed the ordering of test in serial8250_interrupt(). > - Combined test for UPIO_DWAPB with UPIO_MEM in serial8250_start_console(). > - Renamed new uart_8250_port member to private_data. > > 3. Workaround for interrupt/data concurrency issue > - No changes since last patch. > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c > index 3d91bfc..b309c4c 100644 > --- a/drivers/serial/8250.c > +++ b/drivers/serial/8250.c > @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar > return inb(up->port.iobase + 1); > > case UPIO_MEM: > + case UPIO_DWAPB: > return readb(up->port.membase + offset); > > case UPIO_MEM32: > @@ -333,6 +334,8 @@ #endif > static void > serial_out(struct uart_8250_port *up, int offset, int value) > { > + /* Save the offset before it's remapped */ > + int save_offset = offset; > offset = map_8250_out_reg(up, offset) << up->port.regshift; > > switch (up->port.iotype) { > @@ -359,6 +362,18 @@ #endif > writeb(value, up->port.membase + offset); > break; > > + case UPIO_DWAPB: > + /* Save the LCR value so it can be re-written when a > + * Busy Detect interrupt occurs. */ > + if (save_offset == UART_LCR) > + up->lcr = value; > + writeb(value, up->port.membase + offset); > + /* Read the IER to ensure any interrupt is cleared before > + * returning from ISR. */ > + if ((save_offset == UART_TX || save_offset == UART_IER) && in_irq()) > + value = serial_in(up, UART_IER); > + break; > + > default: > outb(value, up->port.iobase + offset); > } > @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u > #ifdef CONFIG_SERIAL_8250_AU1X00 > case UPIO_AU: > #endif > + case UPIO_DWAPB: > serial_out(up, offset, value); > (void)serial_in(up, UART_LCR); /* safe, no side-effects */ > break; > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( > handled = 1; > > end = NULL; > + } else if (up->port.iotype == UPIO_DWAPB && > + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { Worth aligning this line with the opening paren of if... but's that's nitpicking. :-) > + /* The DesignWare APB UART has an Busy Detect (0x07) > + * interrupt meaning an LCR write attempt occured while the > + * UART was busy. The interrupt must be cleared by reading > + * the UART status register (USR) and the LCR re-written. */ > + unsigned int status; > + status = *(volatile u32 *)up->port.private_data; > + serial_out(up, UART_LCR, up->lcr); > + > + handled = 1; > + > + end = NULL; > } else if (end == NULL) > end = l; > > return 0; Still, shouldn't you be doing this in serial8250_timeout() also? What IRQ numbers this UART is using, BTW? > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > index cf23813..bd9711a 100644 > --- a/include/linux/serial_core.h > +++ b/include/linux/serial_core.h > @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( > struct device *dev; /* parent device */ > unsigned char hub6; /* this should be in the 8250 driver */ > unsigned char unused[3]; > + void *private_data; /* generic platform data pointer */ One tab to many before *private_data... > diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h > index 3c8a6aa..1c5ed7d 100644 > --- a/include/linux/serial_reg.h > +++ b/include/linux/serial_reg.h > @@ -38,6 +38,8 @@ #define UART_IIR_THRI 0x02 /* Transmitt > #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ > #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ > > +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ > + > #define UART_FCR 2 /* Out: FIFO Control Register */ > #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ > #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ Oops, your mailer went and did it again. :-) WBR, Sergei From Barry.Bridgman@raymarine.com Thu Feb 8 12:25:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 12:25:50 +0000 (GMT) Received: from mail3.raymarine.com ([213.206.137.1]:48288 "EHLO RMUKMAIL.raymarine.com") by ftp.linux-mips.org with ESMTP id S20038539AbXBHMZm convert rfc822-to-8bit (ORCPT ); Thu, 8 Feb 2007 12:25:42 +0000 X-MimeOLE: Produced By Microsoft Exchange V6.5 Content-class: urn:content-classes:message MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Subject: RE: Toshiba TX4939 Date: Thu, 8 Feb 2007 12:23:14 -0000 Message-ID: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Toshiba TX4939 Thread-Index: AcdLeR2CEU+GdlydTHy/gIl8rAsyFAAAlzbg From: "Barry Bridgman" To: "Sergei Shtylyov" Cc: Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13980 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Barry.Bridgman@raymarine.com Precedence: bulk X-list: linux-mips Hi Sergei Thanks for the Info we have use Montavista in the past for stuff so will give them a call. Thanks Barry -----Original Message----- From: Sergei Shtylyov [mailto:sshtylyov@ru.mvista.com] Sent: 08 February 2007 12:05 To: Barry Bridgman Cc: linux-mips@linux-mips.org Subject: Re: Toshiba TX4939 Hello. Barry Bridgman wrote: > First post on this list as I have come over from xscale and x86 embedded linux designs to a potential MIPS design. > Does anyone know of any sources of information regarding linux on the TX4939 initially on the RBTX4939 development platform. MontaVista has released the 2.6.10 kernel for this board about a year ago. Unfortunately, it hasn't been pushed to Linux/MIPS. > Any info would be gratefully received. I have done some searching for info on the TX4939 but info seems thin on the ground. > Many Thanks > Barry WBR, Sergei From ralf@linux-mips.org Thu Feb 8 12:42:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 12:42:52 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:29599 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038547AbXBHMmu (ORCPT ); Thu, 8 Feb 2007 12:42:50 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l18Cglci010213; Thu, 8 Feb 2007 12:42:48 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l18Cgkbs010212; Thu, 8 Feb 2007 12:42:46 GMT Date: Thu, 8 Feb 2007 12:42:46 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: [MIPS] Do not allow oprofile to be enabled on SMTC. Message-ID: <20070208124246.GA10135@linux-mips.org> References: <20070205.161123.25910611.nemoto@toshiba-tops.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070205.161123.25910611.nemoto@toshiba-tops.co.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13981 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 05, 2007 at 04:11:23PM +0900, Atsushi Nemoto wrote: > !!MIPS_MT_SMTC means MIPS_MT_SMTC!=n ... I guess my keyboard was a bit overzealous that day ;-) Of course this should have been a single exclamation mark. Ralf From ralf@linux-mips.org Thu Feb 8 12:53:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 12:53:10 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:5773 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038560AbXBHMxI (ORCPT ); Thu, 8 Feb 2007 12:53:08 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l18Cr7E4011046; Thu, 8 Feb 2007 12:53:08 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l18Cr6UA011045; Thu, 8 Feb 2007 12:53:06 GMT Date: Thu, 8 Feb 2007 12:53:06 +0000 From: Ralf Baechle To: Yoichi Yuasa Cc: linux-mips Subject: Re: [PATCH][MIPS] removed needless #include on emma2rh Message-ID: <20070208125306.GA10739@linux-mips.org> References: <20070208103029.40481af6.yoichi_yuasa@tripeaks.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070208103029.40481af6.yoichi_yuasa@tripeaks.co.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13982 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 08, 2007 at 10:30:29AM +0900, Yoichi Yuasa wrote: > Hi Ralf, > > These irq.c don't need #include . Applied. Thanks, Ralf From ralf@linux-mips.org Thu Feb 8 13:07:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 13:07:47 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:15778 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038563AbXBHNHp (ORCPT ); Thu, 8 Feb 2007 13:07:45 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l18D7kFb012255; Thu, 8 Feb 2007 13:07:46 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l18D7iRT012254; Thu, 8 Feb 2007 13:07:44 GMT Date: Thu, 8 Feb 2007 13:07:44 +0000 From: Ralf Baechle To: "Maciej W. Rozycki" Cc: Yoichi Yuasa , linux-mips Subject: Re: [PATCH][MIPS] fix run_uncached warning about 32bit kernel Message-ID: <20070208130744.GB10739@linux-mips.org> References: <200702060159.l161xM59075711@mbox33.po.2iij.net> <20070206152817.GB5660@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13983 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 06, 2007 at 06:20:39PM +0000, Maciej W. Rozycki wrote: > > > arch/mips/lib/uncached.c: In function 'run_uncached': > > > arch/mips/lib/uncached.c:47: warning: comparison is always true due to limited range of data type > > > arch/mips/lib/uncached.c:48: warning: comparison is always false due to limited range of data type > > > arch/mips/lib/uncached.c:57: warning: comparison is always true due to limited range of data type > > > arch/mips/lib/uncached.c:58: warning: comparison is always false due to limited range of data type > > > > Thanks, applied. > > "Fixing" bugs in the compiler, huh? ;-) I suppose there should be a note > somewhere nearby then, so there is a remote chance to remove the clutter > in the future. Well, some of the warnings are also simply due to broken code. This is the result of preprocessing the code without Yoichi's patch applied: [...] if (sp >= (long)0x80000000 && sp < (long)0xc0000000) usp = ((((int)(int)(sp)) & 0x1fffffff) | 0xa0000000); else if ((long long)sp >= (long long)(0x8000000000000000LL | ((0LL)<<59) | (0)) && (long long)sp < (long long)(0x8000000000000000LL | ((8LL)<<59) | (0))) usp = (0x8000000000000000LL | (((long long)2)<<59) | ((((long long)sp) & -1))); else { do { __asm__ __volatile__("break %0" : : "i" (512)); } while (0); usp = sp; } [...] So (0x8000000000000000LL | ((0LL)<<59) | (0)) is 0x8000000000000000LL which then is casted to _signed_ long long, so becomes -9223372036854775808, the most negative representable number so the two "comparison is always true due to limited range of data type" warnings are perfectly correct. Treating addresses as signed is a dangerous thing and we reallly only should do it where extending 32-bit addresses to 64-bit because that's what the architecture does. So I would suggest as part of cleaning u the mess something like below totally untested patch. Comments? Ralf Signed-off-by: Ralf Baechle diff --git a/include/asm-mips/addrspace.h b/include/asm-mips/addrspace.h index c627508..ff2dd38 100644 --- a/include/asm-mips/addrspace.h +++ b/include/asm-mips/addrspace.h @@ -10,6 +10,7 @@ #ifndef _ASM_ADDRSPACE_H #define _ASM_ADDRSPACE_H +#include #include /* @@ -22,12 +23,12 @@ #define _CONST64_(x) x #else #define _ATYPE_ __PTRDIFF_TYPE__ -#define _ATYPE32_ int -#define _ATYPE64_ __s64 +#define _ATYPE32_ unsigned int +#define _ATYPE64_ __u64 #ifdef CONFIG_64BIT -#define _CONST64_(x) x ## L +#define _CONST64_(x) x ## UL #else -#define _CONST64_(x) x ## LL +#define _CONST64_(x) x ## ULL #endif #endif From anemo@mba.ocn.ne.jp Thu Feb 8 13:17:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 13:17:28 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:30660 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038566AbXBHNRW (ORCPT ); Thu, 8 Feb 2007 13:17:22 +0000 Received: from localhost (p4240-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id F22A09C55; Thu, 8 Feb 2007 22:15:57 +0900 (JST) Date: Thu, 08 Feb 2007 22:15:58 +0900 (JST) Message-Id: <20070208.221558.74751973.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 0/10] Clean up signal code [take #3] From: Atsushi Nemoto In-Reply-To: References: <20070208.010430.58789357.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13984 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007 10:16:59 +0100, "Franck Bui-Huu" wrote: > BTW, did you have time to try it on a 64-bits kernel ? Yes. No problem for now although not heavily tested. From anemo@mba.ocn.ne.jp Thu Feb 8 13:37:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 13:38:04 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:49858 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038573AbXBHNh6 (ORCPT ); Thu, 8 Feb 2007 13:37:58 +0000 Received: from localhost (p4240-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 66522B649; Thu, 8 Feb 2007 22:36:38 +0900 (JST) Date: Thu, 08 Feb 2007 22:36:37 +0900 (JST) Message-Id: <20070208.223637.108120499.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 9/10] signal: do not use save_static_function() anymore From: Atsushi Nemoto In-Reply-To: References: <11706854703880-git-send-email-fbuihuu@gmail.com> <20070208.004049.51866970.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13985 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007 09:53:18 +0100, "Franck Bui-Huu" wrote: > I tried the following patch: > > diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c > index 229276a..046fb1b 100644 > --- a/arch/mips/kernel/signal.c > +++ b/arch/mips/kernel/signal.c > @@ -68,7 +68,9 @@ int setup_sigcontext(struct pt_regs *regs, struct > sigcontext __user *sc) > err |= __put_user(regs->cp0_epc, &sc->sc_pc); > > err |= __put_user(0, &sc->sc_regs[0]); > - for (i = 1; i < 32; i++) > + for (i = 1; i < 16; i++) > + err |= __put_user(regs->regs[i], &sc->sc_regs[i]); > + for (i = 24; i < 32; i++) > err |= __put_user(regs->regs[i], &sc->sc_regs[i]); > > err |= __put_user(regs->hi, &sc->sc_mdhi); > @@ -126,7 +128,9 @@ int restore_sigcontext(struct pt_regs *regs, > struct sigcontext __user *sc) > err |= __get_user(treg, &sc->sc_dsp); wrdsp(treg, DSP_MASK); > } > > - for (i = 1; i < 32; i++) > + for (i = 1; i < 16; i++) > + err |= __get_user(regs->regs[i], &sc->sc_regs[i]); > + for (i = 24; i < 32; i++) > err |= __get_user(regs->regs[i], &sc->sc_regs[i]); > > err |= __get_user(used_math, &sc->sc_used_math); > > ...and it still passes LTP tests. > > Someone reported that not saving/restoring static registers may break > user tools but the gain is important I think. NO! This change might silently corrupt static registers! If you did not restore static registers in kernel stack on restore_sigcontext(), succeeding RESTORE_STATIC in restore_all will load garbages to static registers. Note that any hardware interrupts in middle of signal handler overwrite pt_regs area in kernel stack. I can still remember random static register corruption bug and how hard to debug ... --- Atsushi Nemoto From jwboyer@linux.vnet.ibm.com Thu Feb 8 13:52:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 13:52:49 +0000 (GMT) Received: from e36.co.us.ibm.com ([32.97.110.154]:12472 "EHLO e36.co.us.ibm.com") by ftp.linux-mips.org with ESMTP id S20038542AbXBHNwo (ORCPT ); Thu, 8 Feb 2007 13:52:44 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e36.co.us.ibm.com (8.13.8/8.13.8) with ESMTP id l18DnQxY027225 for ; Thu, 8 Feb 2007 08:49:26 -0500 Received: from d03av01.boulder.ibm.com (d03av01.boulder.ibm.com [9.17.195.167]) by d03relay04.boulder.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l18DnQ9Z527924 for ; Thu, 8 Feb 2007 06:49:26 -0700 Received: from d03av01.boulder.ibm.com (loopback [127.0.0.1]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l18DnQKd026151 for ; Thu, 8 Feb 2007 06:49:26 -0700 Received: from [9.67.123.9] (wecm-9-67-123-9.wecm.ibm.com [9.67.123.9]) by d03av01.boulder.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l18DnOMO026084; Thu, 8 Feb 2007 06:49:25 -0700 Subject: Re: [PATCH] eXcite nand flash driver From: Josh Boyer To: Thomas Koeller Cc: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org In-Reply-To: <200702080157.25432.thomas.koeller@baslerweb.com> References: <200702080157.25432.thomas.koeller@baslerweb.com> Content-Type: text/plain Date: Thu, 08 Feb 2007 07:50:27 -0600 Message-Id: <1170942627.4884.89.camel@zod.rchland.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13986 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jwboyer@linux.vnet.ibm.com Precedence: bulk X-list: linux-mips On Thu, 2007-02-08 at 01:57 +0100, Thomas Koeller wrote: > > diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig > index 358f55a..5b50396 100644 > --- a/drivers/mtd/nand/Kconfig > +++ b/drivers/mtd/nand/Kconfig > @@ -216,10 +216,26 @@ config MTD_NAND_DISKONCHIP_BBTWRITE > Even if you leave this disabled, you can enable BBT writes at module > load time (assuming you build diskonchip as a module) with the module > parameter "inftl_bbt_write=1". > - > + > config MTD_NAND_SHARPSL > tristate "Support for NAND Flash on Sharp SL Series (C7xx + others)" > depends on MTD_NAND && ARCH_PXA > + > +config MTD_NAND_BASLER_EXCITE > + tristate "Support for NAND Flash on Basler eXcite" > + depends on MTD_NAND && BASLER_EXCITE > + help > + This enables the driver for the NAND flash device found on the > + Basler eXcite Smart Camera. If built as a module, the driver > + will be named "excite_nandflash.ko". > + > +config MTD_NAND_BASLER_EXCITE > + tristate "Support for NAND Flash on Basler eXcite" > + depends on MTD_NAND && BASLER_EXCITE > + help > + This enables the driver for the NAND flash device found on the > + Basler eXcite Smart Camera. If built as a module, the driver > + will be named "excite_nandflash.ko". You have the same config option twice... Cut and paste error? > diff --git a/drivers/mtd/nand/excite_nandflash.c > b/drivers/mtd/nand/excite_nandflash.c > new file mode 100644 > index 0000000..d683659 > --- /dev/null > +++ b/drivers/mtd/nand/excite_nandflash.c > + > +#define io_readb(__a__) __raw_readb((__a__)) > +#define io_writeb(__v__, __a__) __raw_writeb((__v__), (__a__)) Do you really need these defines? Why can't you call __raw_{readb,writeb} directly? > + > +typedef void __iomem *io_reg_t; Ugh... typdef? > +static inline io_reg_t > +excite_nand_map_regs(struct platform_device *d, const char *basename) > +{ > + void *result = NULL; > + const struct resource *const r = > + excite_nand_get_resource(d, IORESOURCE_MEM, basename); > + if (likely(r)) > + result = ioremap_nocache(r->start, r->end + 1 - r->start); Does this likely really buy you anything? I would think doing the converse (if any sort of *likely at all) would be better. > + */ > +static int __exit excite_nand_remove(struct device *dev) > +{ > + struct excite_nand_drvdata * const this = dev_get_drvdata(dev); > + > + dev_set_drvdata(dev, NULL); > + > + if (unlikely(!this)) { > + printk(KERN_ERR "%s: called %s without private data!!", > + module_id, __func__); > + return -EINVAL; > + } > + > + /* first thing we need to do is release our mtd > + * then go through freeing the resource used > + */ > + nand_release(&this->board_mtd); > + > + /* free the common resources */ > + if (likely(this->regs)) { > + iounmap(this->regs); > + this->regs = NULL; > + } Same likely usage comment as above. josh From dedekind@infradead.org Thu Feb 8 14:05:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 14:05:40 +0000 (GMT) Received: from smtp.nokia.com ([131.228.20.172]:20577 "EHLO mgw-ext13.nokia.com") by ftp.linux-mips.org with ESMTP id S20038495AbXBHOFg convert rfc822-to-8bit (ORCPT ); Thu, 8 Feb 2007 14:05:36 +0000 Received: from esebh106.NOE.Nokia.com (esebh106.ntc.nokia.com [172.21.138.213]) by mgw-ext13.nokia.com (Switch-3.2.5/Switch-3.2.5) with ESMTP id l18DrH4D008003; Thu, 8 Feb 2007 15:53:24 +0200 Received: from esebh103.NOE.Nokia.com ([172.21.143.33]) by esebh106.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 15:55:18 +0200 Received: from esebh102.NOE.Nokia.com ([172.21.138.183]) by esebh103.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 15:55:41 +0200 Received: from [172.21.42.38] ([172.21.42.38]) by esebh102.NOE.Nokia.com with Microsoft SMTPSVC(6.0.3790.1830); Thu, 8 Feb 2007 15:55:18 +0200 Subject: Re: [PATCH] eXcite nand flash driver From: Artem Bityutskiy Reply-To: dedekind@infradead.org To: Thomas Koeller Cc: linux-mips@linux-mips.org, linux-mtd@lists.infradead.org, Josh Boyer In-Reply-To: <1170942627.4884.89.camel@zod.rchland.ibm.com> References: <200702080157.25432.thomas.koeller@baslerweb.com> <1170942627.4884.89.camel@zod.rchland.ibm.com> Content-Type: text/plain; charset=UTF-8 Date: Thu, 08 Feb 2007 15:55:40 +0200 Message-Id: <1170942940.7984.5.camel@sauron> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 8BIT X-OriginalArrivalTime: 08 Feb 2007 13:55:18.0152 (UTC) FILETIME=[C4219880:01C74B88] X-Nokia-AV: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13987 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dedekind@infradead.org Precedence: bulk X-list: linux-mips On Thu, 2007-02-08 at 07:50 -0600, Josh Boyer wrote: > > + /* free the common resources */ > > + if (likely(this->regs)) { > > + iounmap(this->regs); > > + this->regs = NULL; > > + } > > Same likely usage comment as above. I agree, this function will be called one or very few times, so this hint is not reasonable in this case. -- Best regards, Artem Bityutskiy (Битюцкий Ðртём) From sergio@amilda.org Thu Feb 8 15:09:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 15:09:58 +0000 (GMT) Received: from www.pc-net.at ([193.238.157.29]:5252 "EHLO MrWeb01.pc-net.at") by ftp.linux-mips.org with ESMTP id S20038614AbXBHPJy (ORCPT ); Thu, 8 Feb 2007 15:09:54 +0000 Received: from localhost (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id DF855215EDC for ; Thu, 8 Feb 2007 16:09:18 +0100 (CET) Received: from MrWeb01.pc-net.at ([127.0.0.1]) by localhost (MrWeb01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 22290-08 for ; Thu, 8 Feb 2007 16:09:14 +0100 (CET) Received: from www.amilda.org (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id 64C45215EDB for ; Thu, 8 Feb 2007 16:09:04 +0100 (CET) Received: from 201.240.249.124 (SquirrelMail authenticated user amilda0001) by www.amilda.org with HTTP; Thu, 8 Feb 2007 10:09:14 -0500 (PET) Message-ID: <13931.201.240.249.124.1170947354.squirrel@www.amilda.org> In-Reply-To: <45CA1552.3080100@wp.pl> References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> <45C3BB23.2070309@wp.pl> <50812.201.230.45.190.1170482268.squirrel@www.amilda.org> <45C45DDA.1000805@wp.pl> <24895.201.240.249.124.1170686083.squirrel@www.amilda.org> <45CA1552.3080100@wp.pl> Date: Thu, 8 Feb 2007 10:09:14 -0500 (PET) Subject: Re: Advice needed. From: "Sergio Aguayo" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.6-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pc-net.at Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13988 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sergio@amilda.org Precedence: bulk X-list: linux-mips > > >>The configuration structure is difficult to understand (even if you have >>the C header containing the struct) >> >> > I don't have any header files for flash. Do you? In tarballs for BR, > there is no source for utilities like flash. > I'm trying to "decode" this structure, variable-by-variable. I have used > your flash utility source > When Edimax was forced to release the sources, they released a different source archive than the one currently available. That one contained some more files than the current one does. I'll upload it today for you to download it. >>Just use the "flash" program. >> >> > The one, that comes with original firmware? But what about webs, as i > looked into, this needs too some knowledge of flash datastructures.? > webs and the flash program share some sources. Originally, flash's sources are contained in the LINUX directory of webs. > > About webs -> will try to add some printf for debugging, and see. > Ok, let me know what your results are. > BTW, maybe the JP3 connector (just 12 little holes) is the JTAG. Will > upload photo i think tomorrow. I have checked this with ohmometer and > pin-map of 8186, and it seems to be JTAG + RESET+ something(?). You have > published schema of JTAG cable, but what software shall anyone use? > That's a JTAG. But AFAIK no software can drive it yet (except maybe some commercial software?). See forum.amilda.org, forum MODs for some information that may be useful for you to experiment with jtag. Sergio From sergio@amilda.org Thu Feb 8 15:17:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 15:17:47 +0000 (GMT) Received: from www.pc-net.at ([193.238.157.29]:23940 "EHLO MrWeb01.pc-net.at") by ftp.linux-mips.org with ESMTP id S20038527AbXBHPRn (ORCPT ); Thu, 8 Feb 2007 15:17:43 +0000 Received: from localhost (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id B8368215ED0 for ; Thu, 8 Feb 2007 16:17:07 +0100 (CET) Received: from MrWeb01.pc-net.at ([127.0.0.1]) by localhost (MrWeb01 [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 25511-02 for ; Thu, 8 Feb 2007 16:16:56 +0100 (CET) Received: from www.amilda.org (localhost [127.0.0.1]) by MrWeb01.pc-net.at (Postfix) with ESMTP id D06D7215ECC for ; Thu, 8 Feb 2007 16:16:46 +0100 (CET) Received: from 201.240.249.124 (SquirrelMail authenticated user amilda0001) by www.amilda.org with HTTP; Thu, 8 Feb 2007 10:16:56 -0500 (PET) Message-ID: <13985.201.240.249.124.1170947816.squirrel@www.amilda.org> In-Reply-To: <45CA1552.3080100@wp.pl> References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> <45C3BB23.2070309@wp.pl> <50812.201.230.45.190.1170482268.squirrel@www.amilda.org> <45C45DDA.1000805@wp.pl> <24895.201.240.249.124.1170686083.squirrel@www.amilda.org> <45CA1552.3080100@wp.pl> Date: Thu, 8 Feb 2007 10:16:56 -0500 (PET) Subject: Re: Advice needed. From: "Sergio Aguayo" To: linux-mips@linux-mips.org User-Agent: SquirrelMail/1.4.6-rc1 MIME-Version: 1.0 Content-Type: text/plain;charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) Importance: Normal X-Virus-Scanned: by amavisd-new-20030616-p10 (Debian) at pc-net.at Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13989 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sergio@amilda.org Precedence: bulk X-list: linux-mips > > >>The configuration structure is difficult to understand (even if you have >>the C header containing the struct) >> >> > I don't have any header files for flash. Do you? In tarballs for BR, > there is no source for utilities like flash. > I'm trying to "decode" this structure, variable-by-variable. I have used > your flash utility source > When Edimax was forced to release the sources, they released a different source archive than the one currently available. That one contained some more files than the current one does. I'll upload it today for you to download it. >>Just use the "flash" program. >> >> > The one, that comes with original firmware? But what about webs, as i > looked into, this needs too some knowledge of flash datastructures.? > webs and the flash program share some sources. Originally, flash's sources are contained in the LINUX directory of webs. > > About webs -> will try to add some printf for debugging, and see. > Ok, let me know what your results are. > BTW, maybe the JP3 connector (just 12 little holes) is the JTAG. Will > upload photo i think tomorrow. I have checked this with ohmometer and > pin-map of 8186, and it seems to be JTAG + RESET+ something(?). You have > published schema of JTAG cable, but what software shall anyone use? > That's a JTAG. But AFAIK no software can drive it yet (except maybe some commercial software?). See forum.amilda.org, forum MODs for some information that may be useful for you to experiment with jtag. Sergio From anemo@mba.ocn.ne.jp Thu Feb 8 15:24:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 15:24:50 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:32224 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038557AbXBHPYo (ORCPT ); Thu, 8 Feb 2007 15:24:44 +0000 Received: from localhost (p4240-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 827BAB671; Fri, 9 Feb 2007 00:23:23 +0900 (JST) Date: Fri, 09 Feb 2007 00:23:23 +0900 (JST) Message-Id: <20070209.002323.115905985.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, macro@linux-mips.org, vagabon.xyz@gmail.com Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: <20070208.120219.96684712.nemoto@toshiba-tops.co.jp> References: <20070208.012216.103777705.anemo@mba.ocn.ne.jp> <20070208.120219.96684712.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13990 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 08 Feb 2007 12:02:19 +0900 (JST), Atsushi Nemoto wrote: > So we can do it in C, but it will conflicts with Franck's signal > cleanup patchset. I hope his patchset applied first. > > Also I wonder SIGSEGV is correct behavior on this case. SIGFPE? And I found that if signal handler set FPU_CSR_UNI_X, kernel complains "FP exception in kernel code" ... Here is a first cut. Changes in r4k_fpu.S can be reverted, and after Franck's patchset applied, this patch can be a bit smaller. Please review. Note that calling __get_user(), __put_user() might lose FPU ownership. But restore_fp_context() already has this breakage. I already sent two alternative patches to fix this longstanding issue ("[PATCH] rewrite restore_fp_context/save_fp_context" and "[PATCH 2/3] Allow CpU exception in kernel partially"). diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index b1f09d5..0811298 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -66,6 +66,38 @@ out: } static inline int +fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static inline int +check_and_restore_fp_context(struct sigcontext __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context(sc); + return err ?: sig; +} + +static inline int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { unsigned int used_math; @@ -112,7 +144,8 @@ restore_sigcontext(struct pt_regs *regs, if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context(sc); + if (!err) + err = check_and_restore_fp_context(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 9a44053..31d8ec0 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -190,6 +190,7 @@ _sys_sigreturn(nabi_no_regargs struct pt { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -203,8 +204,12 @@ _sys_sigreturn(nabi_no_regargs struct pt recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->sf_sc)) + sig = restore_sigcontext(®s, &frame->sf_sc); goto badframe; + if (sig < 0) + goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -228,6 +233,7 @@ _sys_rt_sigreturn(nabi_no_regargs struct struct rt_sigframe __user *frame; sigset_t set; stack_t st; + int sig; frame = (struct rt_sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -241,8 +247,11 @@ _sys_rt_sigreturn(nabi_no_regargs struct recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); if (__copy_from_user(&st, &frame->rs_uc.uc_stack, sizeof(st))) goto badframe; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index c86a5dd..51eb21d 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -326,6 +326,38 @@ asmlinkage int sys32_sigaltstack(nabi_no return ret; } +static inline int +fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static inline int +check_and_restore_fp_context32(struct sigcontext32 __user *sc) +{ + int err, sig; + + sig = fpcsr_pending(&sc->sc_fpc_csr); + if (sig < 0) + err = sig; + err |= restore_fp_context32(sc); + return err ?: sig; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) { u32 used_math; @@ -372,7 +404,8 @@ static int restore_sigcontext32(struct p if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context32(sc); + if (!err) + err = check_and_restore_fp_context(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -469,6 +502,7 @@ _sys32_sigreturn(nabi_no_regargs struct { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -482,8 +516,11 @@ _sys32_sigreturn(nabi_no_regargs struct recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->sf_sc)) + sig = restore_sigcontext32(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... From vagabon.xyz@gmail.com Thu Feb 8 15:40:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 15:40:49 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.224]:57845 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038595AbXBHPko (ORCPT ); Thu, 8 Feb 2007 15:40:44 +0000 Received: by qb-out-0506.google.com with SMTP id e12so79517qba for ; Thu, 08 Feb 2007 07:39:43 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=AUNyRSTkYnrSmhhea0ByVb06xwXGyVVvGHRBxiW+aKdSKwfBDXJYXbYcYVNQMXsrRIL0U1eB6amK0xKv5wMWQBIFYebHc1gYzKj5o1XJD9QgfVkpC0tZhx3H92XTOXJVFCGILfW2CaJri7AeWi9XGx30dpBcJBHmWnFiIeI+5ik= Received: by 10.115.17.1 with SMTP id u1mr4257577wai.1170949183097; Thu, 08 Feb 2007 07:39:43 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 07:39:42 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 16:39:42 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 9/10] signal: do not use save_static_function() anymore Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070208.223637.108120499.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11706854703880-git-send-email-fbuihuu@gmail.com> <20070208.004049.51866970.anemo@mba.ocn.ne.jp> <20070208.223637.108120499.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13991 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Atsushi Nemoto wrote: > If you did not restore static registers in kernel stack on > restore_sigcontext(), succeeding RESTORE_STATIC in restore_all will > load garbages to static registers. > You're right the patch I sent is not sufficient. However, we actually could restore save_static_function (well if we do it, I think it's much better to do it in assembly code...) for sys_sigreturn() _only_. In that case RESTORE_STATIC should load correct values, shouldn't it ? But the points are: - get rid of saving static registers in setup_sigcontext() - get rid of restoring static registers in restore_sigcontext() - free space in the signal frame what do you think ? -- Franck From tglx@linutronix.de Thu Feb 8 15:49:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 15:49:25 +0000 (GMT) Received: from www.osadl.org ([213.239.205.134]:7403 "EHLO mail.tglx.de") by ftp.linux-mips.org with ESMTP id S20038595AbXBHPtT (ORCPT ); Thu, 8 Feb 2007 15:49:19 +0000 Received: from [IPv6:::1] (debian [213.239.205.147]) by mail.tglx.de (Postfix) with ESMTP id B91CE65C065; Thu, 8 Feb 2007 16:48:47 +0100 (CET) Subject: Re: [PATCH] eXcite nand flash driver From: Thomas Gleixner To: Thomas Koeller Cc: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org In-Reply-To: <200702080157.25432.thomas.koeller@baslerweb.com> References: <200702080157.25432.thomas.koeller@baslerweb.com> Content-Type: text/plain Date: Thu, 08 Feb 2007 16:48:57 +0100 Message-Id: <1170949737.3646.29.camel@chaos> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13992 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tglx@linutronix.de Precedence: bulk X-list: linux-mips On Thu, 2007-02-08 at 01:57 +0100, Thomas Koeller wrote: > +static inline const struct resource *excite_nand_get_resource > + (struct platform_device *d, unsigned long flags, const char *basename) { Move curly bracket to new line. > + const char fmt[] = "%s_%u"; Please move the format into the snprintf > + char buf[80]; > + > + if (unlikely > + (snprintf(buf, sizeof buf, fmt, basename, d->id) >= sizeof buf)) > + return NULL; Useless unlikely > + return platform_get_resource_byname(d, flags, buf); > +} > + > +static inline io_reg_t > +excite_nand_map_regs(struct platform_device *d, const char *basename) > +{ > + void *result = NULL; > + const struct resource *const r = > + excite_nand_get_resource(d, IORESOURCE_MEM, basename); Blank line between variable declaration and code. > + if (likely(r)) > + result = ioremap_nocache(r->start, r->end + 1 - r->start); Useless likely > + return result; > +} > +/* command and control functions */ > +static void excite_nand_control(struct mtd_info *mtd, int cmd, > + unsigned int ctrl) > +{ > + io_reg_t regs = > + container_of(mtd, struct excite_nand_drvdata, board_mtd)->regs; > + static void __iomem *tgt = NULL; > + > + switch (ctrl) { > + case NAND_CTRL_CHANGE | NAND_CTRL_CLE: > + tgt = regs + EXCITE_NANDFLASH_CMD_BYTE; > + break; > + case NAND_CTRL_CHANGE | NAND_CTRL_ALE: > + tgt = regs + EXCITE_NANDFLASH_ADDR_BYTE; > + break; > + case NAND_CTRL_CHANGE | NAND_NCE: > + tgt = regs + EXCITE_NANDFLASH_DATA_BYTE; > + break; > + } Err, did this ever work ? I doubt it. From nand_base.c: chip->cmd_ctrl(mtd, page_addr, ctrl); ctrl &= ~NAND_CTRL_CHANGE; chip->cmd_ctrl(mtd, page_addr >> 8, ctrl); So I expect an OOPS happens on a regular base. > +static int excite_nand_devready(struct mtd_info *mtd) > +{ > + struct excite_nand_drvdata * const drvdata = > + container_of(mtd, struct excite_nand_drvdata, board_mtd); Blank line missing > + return io_readb(drvdata->regs + EXCITE_NANDFLASH_STATUS_BYTE); > +} > + > +/* excite_nand_remove > + * > + * called by device layer to remove the driver > + * the binding to the mtd and all allocated > + * resources are released > + */ > +static int __exit excite_nand_remove(struct device *dev) > +{ > + struct excite_nand_drvdata * const this = dev_get_drvdata(dev); > + > + dev_set_drvdata(dev, NULL); > + > + if (unlikely(!this)) { > + printk(KERN_ERR "%s: called %s without private data!!", > + module_id, __func__); > + return -EINVAL; > + } > + > + /* first thing we need to do is release our mtd > + * then go through freeing the resource used > + */ > + nand_release(&this->board_mtd); > + > + /* free the common resources */ > + if (likely(this->regs)) { Why should you ever come here with no mapping ? tglx From macro@linux-mips.org Thu Feb 8 15:50:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 15:50:26 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:40208 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038595AbXBHPuV (ORCPT ); Thu, 8 Feb 2007 15:50:21 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id BE062E1CBA; Thu, 8 Feb 2007 16:49:35 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 2fh4sOmQbFsB; Thu, 8 Feb 2007 16:49:35 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1AA0AE1CBE; Thu, 8 Feb 2007 16:49:35 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l18FnjYW030235; Thu, 8 Feb 2007 16:49:46 +0100 Date: Thu, 8 Feb 2007 15:49:41 +0000 (GMT) From: "Maciej W. Rozycki" To: Franck Bui-Huu cc: Atsushi Nemoto , dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org Subject: Re: RFC: Sentosa boot fix In-Reply-To: Message-ID: References: <20070129161450.GA3384@nevyn.them.org> <20070130.234537.126574565.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2538/Thu Feb 8 15:37:31 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13993 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 1 Feb 2007, Franck Bui-Huu wrote: > It gives good default behaviours without both user's intervention or > configuration: > > if CONFIG_64BITS > ifndef sym32 > if load-y in XKPHYS > sym32 = '' [1] > elif load-y in CKSEG0 > sym32 = '-msym32' [2] > else > if sym32 eq 'yes' > sym32 = '-msym32' [3] > endef > fi > cflags-y += $(sym32) > > [1] since there is no reason to add '-msym32' and it would generate > wrong code anyways. > [2] since it's used by all platforms to generate smaller code. > Warn if this option is not supported by the tool chains. > [3] if you really want to generate code loaded in CKSEG0 without > -msym32 switch you could always do: > > $ make sym32=no Well, it seems fair enough indeed, as long as the availability of "-msym32" is verified as suggested by Atsushi-san. > IMHO, for normal users, this case is probably a configuration > bug and that's the reason we should request for a user to ask for > it explicitly. Hmm, that just raises the question for a definition of who a "normal user" is. And in general -- what "normality" is and why exactly that and not something else. ;-) Maciej From vagabon.xyz@gmail.com Thu Feb 8 16:31:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 16:31:35 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.228]:11446 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038609AbXBHQbb (ORCPT ); Thu, 8 Feb 2007 16:31:31 +0000 Received: by qb-out-0506.google.com with SMTP id e12so84619qba for ; Thu, 08 Feb 2007 08:30:30 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=hlhcRTXMF7LExNHjteVbFAG7fddNT46TB1TcqXBWACLriS9xR/fQmhtUqka4qm5uptMyBqS4B0ikL95Xj7WDJAcVULfwuE9RIW7cMzOTsEWm48ydg22D/8mleIdgnlnLyNPQqov6Uf+mF+BOyXdpXln7x8xtxpA+yYDoM7qikHI= Received: by 10.114.75.1 with SMTP id x1mr4374091waa.1170952229739; Thu, 08 Feb 2007 08:30:29 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 08:30:29 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 17:30:29 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org In-Reply-To: <20070209.002323.115905985.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070208.012216.103777705.anemo@mba.ocn.ne.jp> <20070208.120219.96684712.nemoto@toshiba-tops.co.jp> <20070209.002323.115905985.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13994 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/8/07, Atsushi Nemoto wrote: > On Thu, 08 Feb 2007 12:02:19 +0900 (JST), Atsushi Nemoto wrote: > Here is a first cut. Changes in r4k_fpu.S can be reverted, and after > Franck's patchset applied, this patch can be a bit smaller. Please > review. > yes this's going to conflict a lot with the patchset I sent... [snip] > +static inline int > restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) > { > unsigned int used_math; > @@ -112,7 +144,8 @@ restore_sigcontext(struct pt_regs *regs, > if (used_math()) { sorry for the stupid question but I don't know fpu code...Here used_math() function is used as condition whereas used_math local is already defined. Are we sure we want to use the function here ? -- Franck From anemo@mba.ocn.ne.jp Thu Feb 8 16:36:28 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 16:36:33 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:6113 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038601AbXBHQg2 (ORCPT ); Thu, 8 Feb 2007 16:36:28 +0000 Received: from localhost (p4240-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 41E3E856F; Fri, 9 Feb 2007 01:35:07 +0900 (JST) Date: Fri, 09 Feb 2007 01:35:07 +0900 (JST) Message-Id: <20070209.013507.52129192.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 9/10] signal: do not use save_static_function() anymore From: Atsushi Nemoto In-Reply-To: References: <20070208.223637.108120499.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13995 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007 16:39:42 +0100, "Franck Bui-Huu" wrote: > You're right the patch I sent is not sufficient. However, we actually > could restore save_static_function (well if we do it, I think it's > much better to do it in assembly code...) for sys_sigreturn() _only_. > In that case RESTORE_STATIC should load correct values, shouldn't it ? Yes. I think you are right. > But the points are: > > - get rid of saving static registers in setup_sigcontext() > - get rid of restoring static registers in restore_sigcontext() > - free space in the signal frame I'm afraid of ABI compatibility. Someone might try to handle SIGSEGV and dump all registers to debug the program without debugger... --- Atsushi Nemoto From vagabon.xyz@gmail.com Thu Feb 8 16:37:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 16:38:01 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.239]:47838 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038612AbXBHQh4 (ORCPT ); Thu, 8 Feb 2007 16:37:56 +0000 Received: by qb-out-0506.google.com with SMTP id e12so85189qba for ; Thu, 08 Feb 2007 08:36:55 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=rbiqCVV2u+sz3/QwRf8QQIBs2cOnn+pRPWlP8Uvm1SvlWgmQup4tlx9oBBT+T8dxjy7sjr+WSMJB07NRfBP0lSIWTUw+/Ct4v5XaZZrIpl3tUyD/GXOnbqEHuBjGDias0SYdIgo8/dpZHcEKt414F1BRgZolgQ2vNdv84/PtQkk= Received: by 10.114.80.4 with SMTP id d4mr4384726wab.1170952614780; Thu, 08 Feb 2007 08:36:54 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 08:36:54 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 17:36:54 +0100 From: "Franck Bui-Huu" To: "Maciej W. Rozycki" Subject: Re: RFC: Sentosa boot fix Cc: "Atsushi Nemoto" , dan@debian.org, linux-mips@linux-mips.org, ralf@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070129161450.GA3384@nevyn.them.org> <20070130.234537.126574565.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13996 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/8/07, Maciej W. Rozycki wrote: > Hmm, that just raises the question for a definition of who a "normal > user" is. With the definition I gave, you don't seem to be a 'normal' user ;) -- Franck From macro@linux-mips.org Thu Feb 8 16:50:48 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 16:50:53 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:16914 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038616AbXBHQus (ORCPT ); Thu, 8 Feb 2007 16:50:48 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 3E1AEE1CC8; Thu, 8 Feb 2007 17:50:03 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id fSWhRwFcOWXJ; Thu, 8 Feb 2007 17:50:02 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 1632BE1CC1; Thu, 8 Feb 2007 17:50:02 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l18GoEQv031009; Thu, 8 Feb 2007 17:50:14 +0100 Date: Thu, 8 Feb 2007 16:50:09 +0000 (GMT) From: "Maciej W. Rozycki" To: Ralf Baechle cc: Yoichi Yuasa , linux-mips Subject: Re: [PATCH][MIPS] fix run_uncached warning about 32bit kernel In-Reply-To: <20070208130744.GB10739@linux-mips.org> Message-ID: References: <200702060159.l161xM59075711@mbox33.po.2iij.net> <20070206152817.GB5660@linux-mips.org> <20070208130744.GB10739@linux-mips.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2538/Thu Feb 8 15:37:31 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13997 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007, Ralf Baechle wrote: > Well, some of the warnings are also simply due to broken code. This is > the result of preprocessing the code without Yoichi's patch applied: > > [...] > if (sp >= (long)0x80000000 && sp < (long)0xc0000000) > usp = ((((int)(int)(sp)) & 0x1fffffff) | 0xa0000000); > else if ((long long)sp >= (long long)(0x8000000000000000LL | ((0LL)<<59) | (0)) && > (long long)sp < (long long)(0x8000000000000000LL | ((8LL)<<59) | (0))) > usp = (0x8000000000000000LL | (((long long)2)<<59) | ((((long long)sp) & -1))); > > else { > do { __asm__ __volatile__("break %0" : : "i" (512)); } while (0); > usp = sp; > } > [...] > > So (0x8000000000000000LL | ((0LL)<<59) | (0)) is 0x8000000000000000LL which > then is casted to _signed_ long long, so becomes -9223372036854775808, the > most negative representable number so the two "comparison is always true > due to limited range of data type" warnings are perfectly correct. They are neither correct nor expected. And the problem is not 0x8000000000000000LL being the most negative representable number, but "sp" being a variable of a 32-bit type and being compared against the constant. In this case GCC seems to completely ignore the cast to "long long" and treats it as if the comparison was done between types of different widths. Try building this program: $ cat range.c int foo(sp_t sp) { if (sp >= (long)0x80000000 && sp < (long)0xc0000000) return 0; else if ((long long)sp >= (long long)0x8000000000000000LL && (long long)sp < (long long)0xc000000000000000LL) return 1; else return 2; } $ mips64el-linux-gcc -O2 -Wall -Dsp_t=long -c range.c $ mips64el-linux-gcc -O2 -Wall -Dsp_t=int -c range.c range.c: In function 'foo': range.c:3: warning: comparison is always false due to limited range of data type range.c:3: warning: comparison is always true due to limited range of data type range.c:5: warning: comparison is always true due to limited range of data type range.c:6: warning: comparison is always false due to limited range of data type $ Notice how GCC complains about both 0x8000000000000000LL and 0xc000000000000000LL. I think there was a bug report associated with it -- let me see... Yep: "http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12963". > Treating addresses as signed is a dangerous thing and we reallly only > should do it where extending 32-bit addresses to 64-bit because that's > what the architecture does. So I would suggest as part of cleaning u the > mess something like below totally untested patch. I have used signed types here on purpose not to cross to the user segment (positive range) accidentally. But I do not insist on keeping them if they were to hurt somebody's eyes. Your change is not going to fix the problem anyway -- if I change the condition in the program above to: else if ((unsigned long long)sp >= (unsigned long long)0x8000000000000000ULL && (unsigned long long)sp < (unsigned long long)0xc000000000000000ULL) then unfortunately the warnings persist (I am pretty sure I did this kind of testing before committing these bits, to make sure the warning was unavoidable). Maciej From anemo@mba.ocn.ne.jp Thu Feb 8 16:55:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 16:55:31 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:51960 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038631AbXBHQz0 (ORCPT ); Thu, 8 Feb 2007 16:55:26 +0000 Received: from localhost (p4240-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 9A23A867E; Fri, 9 Feb 2007 01:54:05 +0900 (JST) Date: Fri, 09 Feb 2007 01:54:05 +0900 (JST) Message-Id: <20070209.015405.08319291.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: References: <20070208.120219.96684712.nemoto@toshiba-tops.co.jp> <20070209.002323.115905985.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13998 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007 17:30:29 +0100, "Franck Bui-Huu" wrote: > yes this's going to conflict a lot with the patchset I sent... Here is a patch can be applied on top of your patchset. Subject: Check FCSR for pending interrupts, alternative version The commit 6d6671066a311703bca1b91645bb1e04cc983387 is incomplete and misses non-r4k CPUs. This patch reverts the commit and fixes in other way. * Do FCSR checking in caller of restore_fp_context. * Send SIGFPE if the signal handler set any FPU exception bits. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/r4k_fpu.S | 16 ------------ arch/mips/kernel/signal-common.h | 3 ++ arch/mips/kernel/signal.c | 46 ++++++++++++++++++++++++++++++++++--- arch/mips/kernel/signal32.c | 27 +++++++++++++++++++-- 4 files changed, 70 insertions(+), 22 deletions(-) diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S index 59c1577..dbd42ad 100644 --- a/arch/mips/kernel/r4k_fpu.S +++ b/arch/mips/kernel/r4k_fpu.S @@ -114,14 +114,6 @@ LEAF(_save_fp_context32) */ LEAF(_restore_fp_context) EX lw t0, SC_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - #ifdef CONFIG_64BIT EX ldc1 $f1, SC_FPREGS+8(a0) EX ldc1 $f3, SC_FPREGS+24(a0) @@ -165,14 +157,6 @@ LEAF(_restore_fp_context) LEAF(_restore_fp_context32) /* Restore an o32 sigcontext. */ EX lw t0, SC32_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - EX ldc1 $f0, SC32_FPREGS+0(a0) EX ldc1 $f2, SC32_FPREGS+16(a0) EX ldc1 $f4, SC32_FPREGS+32(a0) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index 9a8abd6..1f24288 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -61,4 +61,7 @@ extern void __user *get_sigframe(struct */ extern int install_sigtramp(unsigned int __user *tramp, unsigned int syscall); +/* Check and clear pending FPU exceptions in saved CSR */ +extern int fpcsr_pending(unsigned int __user *fpcsr); + #endif /* __SIGNAL_COMMON_H */ diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 8dfb7b1..d7531d5 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -103,6 +103,37 @@ int setup_sigcontext(struct pt_regs *reg return err; } +int fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static int +check_and_restore_fp_context(struct sigcontext __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context(sc); + return err ?: sig; +} + int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { unsigned int used_math; @@ -137,7 +168,8 @@ int restore_sigcontext(struct pt_regs *r if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context(sc); + if (!err) + err = check_and_restore_fp_context(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -307,6 +339,7 @@ asmlinkage void sys_sigreturn(nabi_no_re { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -320,8 +353,11 @@ asmlinkage void sys_sigreturn(nabi_no_re recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->sf_sc)) + sig = restore_sigcontext(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -343,6 +379,7 @@ asmlinkage void sys_rt_sigreturn(nabi_no struct rt_sigframe __user *frame; sigset_t set; stack_t st; + int sig; frame = (struct rt_sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -356,8 +393,11 @@ asmlinkage void sys_rt_sigreturn(nabi_no recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); if (__copy_from_user(&st, &frame->rs_uc.uc_stack, sizeof(st))) goto badframe; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 183fc7e..c37ff65 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -207,6 +207,18 @@ static int setup_sigcontext32(struct pt_ return err; } +static int +check_and_restore_fp_context32(struct sigcontext32 __user *sc) +{ + int err, sig; + + sig = fpcsr_pending(&sc->sc_fpc_csr); + if (sig < 0) + err = sig; + err |= restore_fp_context32(sc); + return err ?: sig; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) { @@ -242,7 +254,8 @@ static int restore_sigcontext32(struct p if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context32(sc); + if (!err) + err = check_and_restore_fp_context32(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -495,6 +508,7 @@ asmlinkage void sys32_sigreturn(nabi_no_ { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -508,8 +522,11 @@ asmlinkage void sys32_sigreturn(nabi_no_ recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->sf_sc)) + sig = restore_sigcontext32(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -532,6 +549,7 @@ asmlinkage void sys32_rt_sigreturn(nabi_ sigset_t set; stack_t st; s32 sp; + int sig; frame = (struct rt_sigframe32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -545,8 +563,11 @@ asmlinkage void sys32_rt_sigreturn(nabi_ recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext32(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* The ucontext contains a stack32_t, so we must convert! */ if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp)) From anemo@mba.ocn.ne.jp Thu Feb 8 17:05:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 17:05:23 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:47075 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038618AbXBHRFR (ORCPT ); Thu, 8 Feb 2007 17:05:17 +0000 Received: from localhost (p4240-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 3FDD8B3C0; Fri, 9 Feb 2007 02:03:56 +0900 (JST) Date: Fri, 09 Feb 2007 02:03:55 +0900 (JST) Message-Id: <20070209.020355.45178614.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: References: <20070208.120219.96684712.nemoto@toshiba-tops.co.jp> <20070209.002323.115905985.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 13999 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Thu, 8 Feb 2007 17:30:29 +0100, "Franck Bui-Huu" wrote: > > unsigned int used_math; > > @@ -112,7 +144,8 @@ restore_sigcontext(struct pt_regs *regs, > > if (used_math()) { > > sorry for the stupid question but I don't know fpu code...Here > used_math() function is used as condition whereas used_math local is > already defined. Are we sure we want to use the function here ? Well, used_math() returns condition which are set by preceeding conditional_used_math(). In this case the condition is used_math :) Maybe we can use the used_math variable here to optimize a bit. --- Atsushi Nemoto From laurentp@wp.pl Thu Feb 8 17:38:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 17:39:00 +0000 (GMT) Received: from mx5.wp.pl ([212.77.101.9]:3730 "EHLO mx1.wp.pl") by ftp.linux-mips.org with ESMTP id S20038604AbXBHRiz (ORCPT ); Thu, 8 Feb 2007 17:38:55 +0000 Received: (wp-smtpd smtp.wp.pl 23002 invoked from network); 8 Feb 2007 18:37:50 +0100 Received: from apn-239-93.gprsbal.plusgsm.pl (HELO [87.251.239.93]) (laurentp@[87.251.239.93]) (envelope-sender ) by smtp.wp.pl (WP-SMTPD) with AES256-SHA encrypted SMTP for ; 8 Feb 2007 18:37:50 +0100 Message-ID: <45CB60B9.2000204@wp.pl> Date: Thu, 08 Feb 2007 18:41:13 +0100 From: "W.P." User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.12) Gecko/20050920 X-Accept-Language: pl, en, en-us MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: Advice needed. References: <45C0C956.2050009@wp.pl> <20916.201.240.249.124.1170279547.squirrel@www.amilda.org> <200701312302.05473.florian.fainelli@int-evry.fr> <45C11812.9050808@wp.pl> <10879.201.240.249.124.1170335347.squirrel@www.amilda.org> <45C1FE3D.8080304@wp.pl> <16445.201.240.249.124.1170423826.squirrel@www.amilda.org> <45C3BB23.2070309@wp.pl> <50812.201.230.45.190.1170482268.squirrel@www.amilda.org> <45C45DDA.1000805@wp.pl> <24895.201.240.249.124.1170686083.squirrel@www.amilda.org> <45CA1552.3080100@wp.pl> <13985.201.240.249.124.1170947816.squirrel@www.amilda.org> In-Reply-To: <13985.201.240.249.124.1170947816.squirrel@www.amilda.org> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-WP-AV: skaner antywirusowy poczty Wirtualnej Polski S. A. X-WP-SPAM: NO 0000000 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14000 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: laurentp@wp.pl Precedence: bulk X-list: linux-mips Użytkownik Sergio Aguayo napisaÅ‚: >> >>When Edimax was forced to release the sources, they released a different >>source archive than the one currently available. That one contained some >>more files than the current one does. I'll upload it today for you to >>download it. >> >> OK, i'll wait for it. Please notify me. >webs and the flash program share some sources. Originally, flash's sources >are contained in the LINUX directory of webs. > > > This is why i am "disassembling" data structure. Looks like using a lot of space -> 0x7FFA if the 2 bytes after signature are the length. If i have found correctly, config data is 0x8000->0xFFFA in mdt, a bit earlier are hardware parameters: 0x6000, and there is something (maybe default config) at 0x6400. >> About webs -> will try to add some printf for debugging, and see. At this moment, have located, that problem is in flash parameters loading (before socket binding etc), so i'll finish "dissasembling" and return to webs. >That's a JTAG. But AFAIK no software can drive it yet (except maybe some >commercial software?). See forum.amilda.org, forum MODs for some >information that may be useful for you to experiment with jtag. > > Will look on the net, it's hard to believe, that no one developed JTAG open source software. W.Piotrzkowski. From vagabon.xyz@gmail.com Thu Feb 8 20:06:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 08 Feb 2007 20:06:09 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.234]:26645 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038678AbXBHUGF (ORCPT ); Thu, 8 Feb 2007 20:06:05 +0000 Received: by nz-out-0506.google.com with SMTP id x7so623665nzc for ; Thu, 08 Feb 2007 12:05:03 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=O7er7CwmzqEvt3Ht1aRStkfp7pHHoWmA8LiHXA1poMJ7Z0GzvatUQvPDkS4SUG77G1sx/pqAhNk4FjtQa2//lCE3jMtHqrBSe5LilMtq9Qtf1UKcM+QGntDnbaW1mTTAohOroBDWu8jPwVu4LElEKzZDpIv7Begcs/G3oDuX3zg= Received: by 10.115.76.1 with SMTP id d1mr4806894wal.1170965103573; Thu, 08 Feb 2007 12:05:03 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 8 Feb 2007 12:05:03 -0800 (PST) Message-ID: Date: Thu, 8 Feb 2007 21:05:03 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 9/10] signal: do not use save_static_function() anymore Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070209.013507.52129192.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070208.223637.108120499.anemo@mba.ocn.ne.jp> <20070209.013507.52129192.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14001 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/8/07, Atsushi Nemoto wrote: > On Thu, 8 Feb 2007 16:39:42 +0100, "Franck Bui-Huu" wrote: > > But the points are: > > > > - get rid of saving static registers in setup_sigcontext() > > - get rid of restoring static registers in restore_sigcontext() > > - free space in the signal frame > > I'm afraid of ABI compatibility. Someone might try to handle SIGSEGV > and dump all registers to debug the program without debugger... > Yes that's the main issue with this change. We could make it configurable with an option which would depend on CONFIG_EMBEDDED or something. Therefore someone can turn on the optimization if he really wants it on his platform. But we would still lose the extra space gain in the signal frame. Note: I think that such programs can have trouble with current code anyway... What would happen if the sig handler is run when returning from a syscall ? In this case wouldn't sig context contain almost garbage ? -- Franck From yoichi_yuasa@tripeaks.co.jp Fri Feb 9 03:17:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 03:17:54 +0000 (GMT) Received: from mo31.po.2iij.net ([210.128.50.54]:44109 "EHLO mo31.po.2iij.net") by ftp.linux-mips.org with ESMTP id S20039482AbXBIDRt (ORCPT ); Fri, 9 Feb 2007 03:17:49 +0000 Received: by mo.po.2iij.net (mo31) id l193GVw2050720; Fri, 9 Feb 2007 12:16:31 +0900 (JST) Received: from localhost.localdomain (65.126.232.202.bf.2iij.net [202.232.126.65]) by mbox.po.2iij.net (mbox33) id l193GP00008541 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Fri, 9 Feb 2007 12:16:25 +0900 (JST) Date: Fri, 9 Feb 2007 12:16:24 +0900 From: Yoichi Yuasa To: Ralf Baechle Cc: yoichi_yuasa@tripeaks.co.jp, linux-mips Subject: [PATCH][MIPS] Fixed Cobalt UART I/O type Message-Id: <20070209121624.074ab2cd.yoichi_yuasa@tripeaks.co.jp> Organization: TriPeaks Corporation X-Mailer: Sylpheed version 1.0.4 (GTK+ 1.2.10; i386-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14002 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: yoichi_yuasa@tripeaks.co.jp Precedence: bulk X-list: linux-mips This patch has fixed UART I/O type. The cobalt UART device is actually connected to memory resource area. Yoichi Signed-off-by: Yoichi Yuasa diff -pruN -X mips/Documentation/dontdiff mips-orig/arch/mips/cobalt/setup.c mips/arch/mips/cobalt/setup.c --- mips-orig/arch/mips/cobalt/setup.c 2007-02-07 18:24:06.652083250 +0900 +++ mips/arch/mips/cobalt/setup.c 2007-02-08 15:39:32.309132500 +0900 @@ -130,7 +130,7 @@ void __init plat_mem_setup(void) set_io_port_base(CKSEG1ADDR(GT_DEF_PCI0_IO_BASE)); - /* I/O port resource must include UART and LCD/buttons */ + /* I/O port resource must include LCD/buttons */ ioport_resource.end = 0x0fffffff; /* request I/O space for devices used on all i[345]86 PCs */ @@ -149,24 +149,24 @@ void __init plat_mem_setup(void) register_pci_controller(&cobalt_pci_controller); #endif -#ifdef CONFIG_SERIAL_8250 if (cobalt_board_id > COBALT_BRD_ID_RAQ1) { - #ifdef CONFIG_EARLY_PRINTK cobalt_early_console(); #endif +#ifdef CONFIG_SERIAL_8250 uart.line = 0; uart.type = PORT_UNKNOWN; uart.uartclk = 18432000; uart.irq = COBALT_SERIAL_IRQ; - uart.flags = UPF_BOOT_AUTOCONF | UPF_SKIP_TEST; - uart.iobase = 0xc800000; - uart.iotype = UPIO_PORT; + uart.flags = UPF_IOREMAP | UPF_BOOT_AUTOCONF | + UPF_SKIP_TEST; + uart.iotype = UPIO_MEM; + uart.mapbase = 0x1c800000; early_serial_setup(&uart); - } #endif + } } /* From anemo@mba.ocn.ne.jp Fri Feb 9 04:03:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 04:03:48 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:41421 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039580AbXBIEDm (ORCPT ); Fri, 9 Feb 2007 04:03:42 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Fri, 9 Feb 2007 13:03:40 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 40B8F261FB; Fri, 9 Feb 2007 13:03:17 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 2C2B220571; Fri, 9 Feb 2007 13:03:17 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l1943GW0072922; Fri, 9 Feb 2007 13:03:16 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Fri, 09 Feb 2007 13:03:16 +0900 (JST) Message-Id: <20070209.130316.14978798.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: <20070209.015405.08319291.anemo@mba.ocn.ne.jp> References: <20070209.002323.115905985.anemo@mba.ocn.ne.jp> <20070209.015405.08319291.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14003 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Fri, 09 Feb 2007 01:54:05 +0900 (JST), Atsushi Nemoto wrote: > Here is a patch can be applied on top of your patchset. I missed n32 part. Revised. Subject: Check FCSR for pending interrupts, alternative version The commit 6d6671066a311703bca1b91645bb1e04cc983387 is incomplete and misses non-r4k CPUs. This patch reverts the commit and fixes in other way. * Do FCSR checking in caller of restore_fp_context. * Send SIGFPE if the signal handler set any FPU exception bits. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/r4k_fpu.S | 16 ------------ arch/mips/kernel/signal-common.h | 3 ++ arch/mips/kernel/signal.c | 46 ++++++++++++++++++++++++++++++++++--- arch/mips/kernel/signal32.c | 27 +++++++++++++++++++-- arch/mips/kernel/signal_n32.c | 6 ++++ 5 files changed, 75 insertions(+), 23 deletions(-) diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S index 59c1577..dbd42ad 100644 --- a/arch/mips/kernel/r4k_fpu.S +++ b/arch/mips/kernel/r4k_fpu.S @@ -114,14 +114,6 @@ LEAF(_save_fp_context32) */ LEAF(_restore_fp_context) EX lw t0, SC_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - #ifdef CONFIG_64BIT EX ldc1 $f1, SC_FPREGS+8(a0) EX ldc1 $f3, SC_FPREGS+24(a0) @@ -165,14 +157,6 @@ LEAF(_restore_fp_context) LEAF(_restore_fp_context32) /* Restore an o32 sigcontext. */ EX lw t0, SC32_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - EX ldc1 $f0, SC32_FPREGS+0(a0) EX ldc1 $f2, SC32_FPREGS+16(a0) EX ldc1 $f4, SC32_FPREGS+32(a0) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index 9a8abd6..1f24288 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -61,4 +61,7 @@ extern void __user *get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, */ extern int install_sigtramp(unsigned int __user *tramp, unsigned int syscall); +/* Check and clear pending FPU exceptions in saved CSR */ +extern int fpcsr_pending(unsigned int __user *fpcsr); + #endif /* __SIGNAL_COMMON_H */ diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 8dfb7b1..d7531d5 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -103,6 +103,37 @@ int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) return err; } +int fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static int +check_and_restore_fp_context(struct sigcontext __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context(sc); + return err ?: sig; +} + int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { unsigned int used_math; @@ -137,7 +168,8 @@ int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context(sc); + if (!err) + err = check_and_restore_fp_context(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -307,6 +339,7 @@ asmlinkage void sys_sigreturn(nabi_no_regargs struct pt_regs regs) { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -320,8 +353,11 @@ asmlinkage void sys_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->sf_sc)) + sig = restore_sigcontext(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -343,6 +379,7 @@ asmlinkage void sys_rt_sigreturn(nabi_no_regargs struct pt_regs regs) struct rt_sigframe __user *frame; sigset_t set; stack_t st; + int sig; frame = (struct rt_sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -356,8 +393,11 @@ asmlinkage void sys_rt_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); if (__copy_from_user(&st, &frame->rs_uc.uc_stack, sizeof(st))) goto badframe; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 183fc7e..c37ff65 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -207,6 +207,18 @@ static int setup_sigcontext32(struct pt_regs *regs, return err; } +static int +check_and_restore_fp_context32(struct sigcontext32 __user *sc) +{ + int err, sig; + + sig = fpcsr_pending(&sc->sc_fpc_csr); + if (sig < 0) + err = sig; + err |= restore_fp_context32(sc); + return err ?: sig; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) { @@ -242,7 +254,8 @@ static int restore_sigcontext32(struct pt_regs *regs, if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context32(sc); + if (!err) + err = check_and_restore_fp_context32(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -495,6 +508,7 @@ asmlinkage void sys32_sigreturn(nabi_no_regargs struct pt_regs regs) { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -508,8 +522,11 @@ asmlinkage void sys32_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->sf_sc)) + sig = restore_sigcontext32(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -532,6 +549,7 @@ asmlinkage void sys32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) sigset_t set; stack_t st; s32 sp; + int sig; frame = (struct rt_sigframe32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -545,8 +563,11 @@ asmlinkage void sys32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext32(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* The ucontext contains a stack32_t, so we must convert! */ if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp)) diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index 57456e6..01c6627 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -123,6 +123,7 @@ asmlinkage void sysn32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) sigset_t set; stack_t st; s32 sp; + int sig; frame = (struct rt_sigframe_n32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -136,8 +137,11 @@ asmlinkage void sysn32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* The ucontext contains a stack32_t, so we must convert! */ if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp)) From zzh.hust@gmail.com Fri Feb 9 07:31:08 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 07:31:15 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.224]:27840 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037622AbXBIHbI (ORCPT ); Fri, 9 Feb 2007 07:31:08 +0000 Received: by nz-out-0506.google.com with SMTP id x7so762196nzc for ; Thu, 08 Feb 2007 23:30:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=rdG+37l/7OsM+Q1zmMbsEV4aD+CshVefmKhZ67cq8UIIuIkpsBCSeeYBpfk03Fm/s3bLSl/Up1xcpnQ9icMdEh4LIOmmfE8xmOFhN1sUtDTxtLAtDpkzQ7wh2tAtIx/3Xd0ceVJAOfiA3ZSfg/xVi0laaSdW9RkDYIkcBWll2Xs= Received: by 10.114.211.1 with SMTP id j1mr4671871wag.1171006206771; Thu, 08 Feb 2007 23:30:06 -0800 (PST) Received: by 10.114.168.17 with HTTP; Thu, 8 Feb 2007 23:30:06 -0800 (PST) Message-ID: <50c9a2250702082330g3dd5497fq3d3f6be099845a0a@mail.gmail.com> Date: Fri, 9 Feb 2007 15:30:06 +0800 From: zhuzhenhua To: linux-mips Subject: is there a patch to use mmc/sd through bio or make_request? MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14004 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: zzh.hust@gmail.com Precedence: bulk X-list: linux-mips in our board, DMA can not handle sg, so i want to remove blk_rq_map_sg, and just use the bio. is there any patch to do this? thanks for any hints Best Regards zhuzhenhua From vagabon.xyz@gmail.com Fri Feb 9 15:09:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 15:09:41 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.238]:14986 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038755AbXBIPJg (ORCPT ); Fri, 9 Feb 2007 15:09:36 +0000 Received: by qb-out-0506.google.com with SMTP id e12so191984qba for ; Fri, 09 Feb 2007 07:08:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=ZeEj368E+h6+ZHvN0KVX2SPaIYyGtJHPHLWMzN+7GLb4oMM1jREGlfIPlhxMhvrIR7qQvT3tQ6MNOQz4WiVgizWyBL7g7u8yjIDVUpRbKc4vZcTQIl4LwsXiDReHGE4w1DvNccvB/G/exixYNeNfahMmVSIvOgaN1wRY23RXIWI= Received: by 10.65.222.11 with SMTP id z11mr746830qbq.1171033714820; Fri, 09 Feb 2007 07:08:34 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id f18sm3718441qba.2007.02.09.07.08.33; Fri, 09 Feb 2007 07:08:34 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 9AF3323F76A; Fri, 9 Feb 2007 16:07:39 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, Franck Bui-Huu Subject: [PATCH 2/3] signals: make common _BLOCKABLE macro Date: Fri, 9 Feb 2007 16:07:37 +0100 Message-Id: <11710336593668-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171033658561-git-send-email-fbuihuu@gmail.com> References: <1171033658561-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14005 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal-common.h | 2 ++ arch/mips/kernel/signal.c | 2 -- arch/mips/kernel/signal32.c | 2 -- arch/mips/kernel/signal_n32.c | 2 -- 4 files changed, 2 insertions(+), 6 deletions(-) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index 9a8abd6..23fffb4 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -19,6 +19,8 @@ # define DEBUGP(fmt, args...) #endif +#define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) + /* * Horribly complicated - with the bloody RM9000 workarounds enabled * the signal trampolines is moving to the end of the structure so we can diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 464d34b..a3c04d0 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -34,8 +34,6 @@ #include "signal-common.h" -#define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) - #if ICACHE_REFILLS_WORKAROUND_WAR == 0 struct rt_sigframe { diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 183fc7e..f603ff4 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -104,8 +104,6 @@ typedef struct compat_siginfo { #define __NR_O32_rt_sigreturn 4193 #define __NR_O32_restart_syscall 4253 -#define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) - /* 32-bit compatibility types */ #define _NSIG_BPW32 32 diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index 57456e6..51b114f 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -47,8 +47,6 @@ #define __NR_N32_rt_sigreturn 6211 #define __NR_N32_restart_syscall 6214 -#define _BLOCKABLE (~(sigmask(SIGKILL) | sigmask(SIGSTOP))) - /* IRIX compatible stack_t */ typedef struct sigaltstack32 { s32 ss_sp; -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Fri Feb 9 15:10:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 15:10:07 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.238]:16010 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038767AbXBIPJg (ORCPT ); Fri, 9 Feb 2007 15:09:36 +0000 Received: by qb-out-0506.google.com with SMTP id e12so191986qba for ; Fri, 09 Feb 2007 07:08:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=covEI7rV+DYBPHG6BzgSO4OzyckE74rFFd66JmckX09x2eeXYmX9rsZFtjEXGMCNOUgYLTwAteeQ/FmwrDYe/TisIbwuauBkZyewe6hO7Y7xPgBAzpuFlk9TdK1GVTGzAKrXJ/ZaM6ly/6W6e0j3h+Z9xRLag2ohvyxereM6mBQ= Received: by 10.64.10.2 with SMTP id 2mr15978026qbj.1171033715214; Fri, 09 Feb 2007 07:08:35 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id q13sm3530341qbq.2007.02.09.07.08.33; Fri, 09 Feb 2007 07:08:34 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id A848323F772; Fri, 9 Feb 2007 16:07:39 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, Franck Bui-Huu Subject: [PATCH 1/3] signal: avoid useless test in do_signal() Date: Fri, 9 Feb 2007 16:07:36 +0100 Message-Id: <11710336594091-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171033658561-git-send-email-fbuihuu@gmail.com> References: <1171033658561-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14006 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu Indeed we can simply clear the flag whatever its value Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index 8dfb7b1..464d34b 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -552,10 +552,8 @@ void do_signal(struct pt_regs *regs) * and will be restored by sigreturn, so we can simply * clear the TIF_RESTORE_SIGMASK flag. */ - if (test_thread_flag(TIF_RESTORE_SIGMASK)) - clear_thread_flag(TIF_RESTORE_SIGMASK); + clear_thread_flag(TIF_RESTORE_SIGMASK); } - return; } -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Fri Feb 9 15:10:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 15:10:37 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.235]:9350 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038786AbXBIPJh (ORCPT ); Fri, 9 Feb 2007 15:09:37 +0000 Received: by qb-out-0506.google.com with SMTP id e12so191989qba for ; Fri, 09 Feb 2007 07:08:35 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=EpKEZKzApItiYyEeQxtHFvtW9ZzyopOa7K2EUJHrq6dVatBT1M/4ytMRxYK61kl6fgabURU4t3BM7VLG/+SqlxsQ+lpvT8aHNdsEVVMHvwG2si5dhys15F8qahTLxqZ5APsOkBHU/UWCNaRGrZ5cvc171/tnyC3eInltaXM67Kc= Received: by 10.65.224.11 with SMTP id b11mr15913224qbr.1171033715671; Fri, 09 Feb 2007 07:08:35 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id f15sm3694233qba.2007.02.09.07.08.33; Fri, 09 Feb 2007 07:08:34 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id A6BED23F76F; Fri, 9 Feb 2007 16:07:39 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, Franck Bui-Huu Subject: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Date: Fri, 9 Feb 2007 16:07:38 +0100 Message-Id: <11710336591652-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171033658561-git-send-email-fbuihuu@gmail.com> References: <1171033658561-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14007 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This hack prevents gcc to produce the following warning: CC arch/mips/kernel/signal.o arch/mips/kernel/signal.c: In function `sys_sigaction': arch/mips/kernel/signal.c:266: warning: cast to pointer from integer of different size This warning is due to the following line: __get_user(new_ka.sa.sa_handler, &act->sa_handler); Indeed when __get_user() is expanded it produces the following code: switch (sizeof(*(&act->sa_handler))) { ... [snip] ... case 8: { unsigned long long __gu_tmp; __asm__ __volatile__( "1: lw %1, (%3) \n" "2: lw %D1, 4(%3) \n" " move %0, $0 \n" "3: .section .fixup,\"ax\" \n" "4: li %0, %4 \n" " move %1, $0 \n" " move %D1, $0 \n" " j 3b \n" " .previous \n" " .section __ex_table,\"a\" \n" " " ".word" " 1b, 4b \n" " " ".word" " 2b, 4b \n" " .previous \n" : "=r" (__gu_err), "=&r" (__gu_tmp) : "0" (0), "r" ((&act->sa_handler)), "i" (-14)); (((new_ka.sa.sa_handler))) = (__typeof__(*((&act->sa_handler)))) __gu_tmp; }; break; default: __get_user_unknown(); break; } which actually try to do: new_ka.sa.sa_handler = (__sighandler_t) __gu_tmp; Here we try to cast an 'unsigned long long' into a 32 bits pointer and that's the reason of the warning. Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/signal.c | 4 +++- 1 files changed, 3 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index a3c04d0..ac8a05a 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -260,15 +260,17 @@ asmlinkage int sys_sigaction(int sig, const struct sigaction __user *act, if (act) { old_sigset_t mask; + unsigned long tmp; /* fix a gcc warning */ if (!access_ok(VERIFY_READ, act, sizeof(*act))) return -EFAULT; - err |= __get_user(new_ka.sa.sa_handler, &act->sa_handler); + err |= __get_user(tmp, (unsigned long *)&act->sa_handler); err |= __get_user(new_ka.sa.sa_flags, &act->sa_flags); err |= __get_user(mask, &act->sa_mask.sig[0]); if (err) return -EFAULT; + new_ka.sa.sa_handler = (__sighandler_t)tmp; siginitset(&new_ka.sa.sa_mask, mask); } -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Fri Feb 9 15:11:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 15:11:06 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.238]:22154 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038792AbXBIPJh (ORCPT ); Fri, 9 Feb 2007 15:09:37 +0000 Received: by qb-out-0506.google.com with SMTP id e12so191991qba for ; Fri, 09 Feb 2007 07:08:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:from; b=kKHqRGUbfzAc51QRUk+oeVStFC+566YUng/jgiOW1Bn4kHcGW0wRok2Eofje6NLkGyOFR16CeWo0J6GuYR0Mqd9r4cFOVjDcQLRb+QWOV+/0FBp4HdkFlav9iV4jzQke0XZyOo2JOShwmOILVOW4BqPVSfmAAAR1wL26GvOefas= Received: by 10.65.154.2 with SMTP id g2mr15856175qbo.1171033716322; Fri, 09 Feb 2007 07:08:36 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id q13sm3530337qbq.2007.02.09.07.08.34; Fri, 09 Feb 2007 07:08:35 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 4F79E23F770; Fri, 9 Feb 2007 16:07:39 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp Subject: [PATCH 0/3] More signal clean up Date: Fri, 9 Feb 2007 16:07:35 +0100 Message-Id: <1171033658561-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14008 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi Ralf, Sorry for forgetting these 3 trivial patches. It shouldn't conflict with Atsushi's last patch: Check FCSR for pending interrupts, alternative version Please consider, Franck --- arch/mips/kernel/signal-common.h | 2 ++ arch/mips/kernel/signal.c | 10 ++++------ arch/mips/kernel/signal32.c | 2 -- arch/mips/kernel/signal_n32.c | 2 -- 4 files changed, 6 insertions(+), 10 deletions(-) From anemo@mba.ocn.ne.jp Fri Feb 9 16:19:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 16:20:01 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:12755 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038782AbXBIQT4 (ORCPT ); Fri, 9 Feb 2007 16:19:56 +0000 Received: from localhost (p4029-ipad301funabasi.chiba.ocn.ne.jp [122.17.254.29]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 617C0B6EC; Sat, 10 Feb 2007 01:18:35 +0900 (JST) Date: Sat, 10 Feb 2007 01:18:35 +0900 (JST) Message-Id: <20070210.011835.08318488.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, fbuihuu@gmail.com Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel From: Atsushi Nemoto In-Reply-To: <11710336591652-git-send-email-fbuihuu@gmail.com> References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336591652-git-send-email-fbuihuu@gmail.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14009 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Fri, 9 Feb 2007 16:07:38 +0100, Franck Bui-Huu wrote: > CC arch/mips/kernel/signal.o > arch/mips/kernel/signal.c: In function `sys_sigaction': > arch/mips/kernel/signal.c:266: warning: cast to pointer from integer of different size > > This warning is due to the following line: > > __get_user(new_ka.sa.sa_handler, &act->sa_handler); This usage of __get_user() should be absolutely legal. > new_ka.sa.sa_handler = (__sighandler_t) __gu_tmp; > > Here we try to cast an 'unsigned long long' into a 32 bits pointer and > that's the reason of the warning. This line is never executed on 32bit kernel and gcc optimize out. On 64-bit kernel, this line is executed without any problem without warning. I think this is a problem of __get_user() implementation or gcc itself. Though I can not find better solution yet, hacking the caller to avoid the warning would not be right things to to. --- Atsushi Nemoto From ralf@linux-mips.org Fri Feb 9 16:21:21 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 16:21:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:32651 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038748AbXBIQVV (ORCPT ); Fri, 9 Feb 2007 16:21:21 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l19GLKop028579; Fri, 9 Feb 2007 16:21:20 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l19GLIWw028578; Fri, 9 Feb 2007 16:21:18 GMT Date: Fri, 9 Feb 2007 16:21:18 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, Franck Bui-Huu Subject: Re: [PATCH 1/3] signal: avoid useless test in do_signal() Message-ID: <20070209162118.GA26617@linux-mips.org> References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336594091-git-send-email-fbuihuu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11710336594091-git-send-email-fbuihuu@gmail.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14010 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 09, 2007 at 04:07:36PM +0100, Franck Bui-Huu wrote: > - if (test_thread_flag(TIF_RESTORE_SIGMASK)) > - clear_thread_flag(TIF_RESTORE_SIGMASK); This is a microoptimization. The assumption here is TIF_RESTORE_SIGMASK will rarely need to be cleared and atomic operations are somewhat expensive if as in this case we have to assume the cacheline isn't held exclusive yet. Ralf From fbuihuu@gmail.com Fri Feb 9 16:35:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 16:35:22 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.237]:44650 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038803AbXBIQfR (ORCPT ); Fri, 9 Feb 2007 16:35:17 +0000 Received: by hu-out-0506.google.com with SMTP id 22so360268hug for ; Fri, 09 Feb 2007 08:34:17 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=dvYMMz8Lu2+p0OVTasPFgyb02ZGFzw/DQw+HJLumNqLMDc+i/aD3ztNIIPcpJXnXi6r4Lq6XsOrvu2Bm9O+wP4PwwDp+VuPtJUO9MdXmGlnUmBtdA2Fz9GbACi+S7TqLNVjPBhtYQuEKhL7x9BClZgylvHYQooKD3gs9HuqdP70= Received: by 10.78.20.13 with SMTP id 13mr5013662hut.1171038857030; Fri, 09 Feb 2007 08:34:17 -0800 (PST) Received: by 10.78.183.16 with HTTP; Fri, 9 Feb 2007 08:34:16 -0800 (PST) Message-ID: <61ec3ea90702090834k774bf18bwf7ec5f7b10349779@mail.gmail.com> Date: Fri, 9 Feb 2007 17:34:16 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070210.011835.08318488.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336591652-git-send-email-fbuihuu@gmail.com> <20070210.011835.08318488.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14011 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: fbuihuu@gmail.com Precedence: bulk X-list: linux-mips On 2/9/07, Atsushi Nemoto wrote: > On Fri, 9 Feb 2007 16:07:38 +0100, Franck Bui-Huu wrote: > > new_ka.sa.sa_handler = (__sighandler_t) __gu_tmp; > > > > Here we try to cast an 'unsigned long long' into a 32 bits pointer and > > that's the reason of the warning. > > This line is never executed on 32bit kernel and gcc optimize out. On yes I agree but it seems that gcc compiles this line before optimizing out... > > I think this is a problem of __get_user() implementation or gcc > itself. Though I can not find better solution yet, hacking the caller > to avoid the warning would not be right things to to. I agree too but I haven't found something else. BTW, my version of gcc is: mipsel-linux-gcc (GCC) 3.4.4 mipssde-6.05.00-20061023 thanks -- Franck From vagabon.xyz@gmail.com Fri Feb 9 16:51:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 16:51:45 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.229]:40462 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038769AbXBIQvl (ORCPT ); Fri, 9 Feb 2007 16:51:41 +0000 Received: by qb-out-0506.google.com with SMTP id e12so201449qba for ; Fri, 09 Feb 2007 08:50:36 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=UivTl0Rm2pXaNnmlj9W1NimNSAv/dnzWQhIkITRoqjKY/V0rHfVQLmMR5VXeAenB1DyVp8bzrSVz2y/HmwI0aMdC85mzj0FTc3pnwvE46SBUBsONh5KpYGUFfhujKxvU8mv+QyGQ0X2Wjv00cq2EL+fyKHMuWV9dw4kksUl0Tl4= Received: by 10.114.124.1 with SMTP id w1mr5048739wac.1171039836435; Fri, 09 Feb 2007 08:50:36 -0800 (PST) Received: by 10.114.136.11 with HTTP; Fri, 9 Feb 2007 08:50:36 -0800 (PST) Message-ID: Date: Fri, 9 Feb 2007 17:50:36 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH 1/3] signal: avoid useless test in do_signal() Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, "Franck Bui-Huu" In-Reply-To: <20070209162118.GA26617@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336594091-git-send-email-fbuihuu@gmail.com> <20070209162118.GA26617@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14012 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/9/07, Ralf Baechle wrote: Ralf Baechle wrote: > On Fri, Feb 09, 2007 at 04:07:36PM +0100, Franck Bui-Huu wrote: > >> - if (test_thread_flag(TIF_RESTORE_SIGMASK)) >> - clear_thread_flag(TIF_RESTORE_SIGMASK); > > This is a microoptimization. The assumption here is TIF_RESTORE_SIGMASK > will rarely need to be cleared and atomic operations are somewhat > expensive if as in this case we have to assume the cacheline isn't > held exclusive yet. > I missed that. You can forget this patch or maybe something like this is more appropriate ? if (unlikely(test_thread_flag(TIF_RESTORE_SIGMASK))) clear_thread_flag(TIF_RESTORE_SIGMASK); -- Franck From Marc_St-Jean@pmc-sierra.com Fri Feb 9 19:40:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 19:40:35 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:21189 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20038813AbXBITk3 (ORCPT ); Fri, 9 Feb 2007 19:40:29 +0000 Received: (qmail 28237 invoked by uid 101); 9 Feb 2007 19:39:11 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by father.pmc-sierra.com with SMTP; 9 Feb 2007 19:39:11 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l19Jd9lK017743; Fri, 9 Feb 2007 11:39:09 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC74MMJ>; Fri, 9 Feb 2007 11:39:09 -0800 Message-ID: <45CCCDD4.7030104@pmc-sierra.com> From: Marc St-Jean To: Sergei Shtylyov Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Fri, 9 Feb 2007 11:39:00 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 09 Feb 2007 19:39:07.0411 (UTC) FILETIME=[F68A7630:01C74C81] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14013 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Sergei Shtylyov wrote: > Marc St-Jean wrote: > > Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx > device. > > > > There are three different fixes: > > 1. Fix for DesignWare THRE errata > > - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" > > tree also fixes it. This patch needs to be applied on top of "mm" patch. > > > > 2. Fix for Busy Detect on LCR write > > - Changed the ordering of test in serial8250_interrupt(). > > - Combined test for UPIO_DWAPB with UPIO_MEM in > serial8250_start_console(). > > - Renamed new uart_8250_port member to private_data. > > > > 3. Workaround for interrupt/data concurrency issue > > - No changes since last patch. > > > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( > > handled = 1; > > > > end = NULL; > > + } else if (up->port.iotype == UPIO_DWAPB && > > + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { > > Worth aligning this line with the opening paren of if... but's that's > nitpicking. :-) No problem I'll change it. I just usually align to the closest tab stop to the opening parenthesis. > > + /* The DesignWare APB UART has an Busy Detect > (0x07) > > + * interrupt meaning an LCR write attempt > occured while the > > + * UART was busy. The interrupt must be cleared > by reading > > + * the UART status register (USR) and the LCR > re-written. */ > > + unsigned int status; > > + status = *(volatile u32 *)up->port.private_data; > > + serial_out(up, UART_LCR, up->lcr); > > + > > + handled = 1; > > + > > + end = NULL; > > } else if (end == NULL) > > end = l; > > > > return 0; > > Still, shouldn't you be doing this in serial8250_timeout() No, the serial8250_timeout is for issue 1 at the top, this is for issue 2. > also? > What IRQ numbers this UART is using, BTW? For the ports on the device they are 27 and 42. Is there any significance that I'm not aware of? > > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h > > index cf23813..bd9711a 100644 > > --- a/include/linux/serial_core.h > > +++ b/include/linux/serial_core.h > > @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( > > struct device *dev; /* parent > device */ > > unsigned char hub6; /* this should > be in the 8250 driver */ > > unsigned char unused[3]; > > + void *private_data; /* > generic platform data pointer */ > > One tab to many before *private_data... In my editor using 4 columns per tab it lines up with everything. Is there some convention that patches should be made assuming 8 columns? > > diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h > > index 3c8a6aa..1c5ed7d 100644 > > --- a/include/linux/serial_reg.h > > +++ b/include/linux/serial_reg.h > > @@ -38,6 +38,8 @@ #define UART_IIR_THRI 0x02 /* Transmitt > > #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ > > #define UART_IIR_RLSI 0x06 /* Receiver line status > interrupt */ > > > > +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy > Detect */ > > + > > #define UART_FCR 2 /* Out: FIFO Control Register */ > > #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ > > #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ > > Oops, your mailer went and did it again. :-) I'm completely giving up on Thunderbird,unless someone can point out the specific internal configuration items which needs a kick! Thanks, Marc From dale@farnsworth.org Fri Feb 9 20:32:49 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 20:32:53 +0000 (GMT) Received: from xyzzy.farnsworth.org ([65.39.95.219]:52743 "HELO farnsworth.org") by ftp.linux-mips.org with SMTP id S20039615AbXBIUct (ORCPT ); Fri, 9 Feb 2007 20:32:49 +0000 Received: (qmail 18094 invoked by uid 1000); 9 Feb 2007 13:31:43 -0700 From: "Dale Farnsworth" Date: Fri, 9 Feb 2007 13:31:43 -0700 To: Ralf Baechle Cc: linux-mips@linux-mips.org Subject: Fix eth2 platform device id for jaguar_atx and ocelot_3 platforms Message-ID: <20070209203142.GA17729@xyzzy.farnsworth.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14014 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dale@farnsworth.org Precedence: bulk X-list: linux-mips From: Dale Farnsworth Signed-off-by: Dale Farnsowrth diff --git a/arch/mips/momentum/jaguar_atx/platform.c b/arch/mips/momentum/jaguar_atx/platform.c index 035ea51..8103770 100644 --- a/arch/mips/momentum/jaguar_atx/platform.c +++ b/arch/mips/momentum/jaguar_atx/platform.c @@ -129,7 +129,7 @@ static struct mv643xx_eth_platform_data static struct platform_device eth2_device = { .name = MV643XX_ETH_NAME, - .id = 1, + .id = 2, .num_resources = ARRAY_SIZE(mv64x60_eth2_resources), .resource = mv64x60_eth2_resources, .dev = { diff --git a/arch/mips/momentum/ocelot_3/platform.c b/arch/mips/momentum/ocelot_3/platform.c index eefe584..57cfe5c 100644 --- a/arch/mips/momentum/ocelot_3/platform.c +++ b/arch/mips/momentum/ocelot_3/platform.c @@ -129,7 +129,7 @@ static struct mv643xx_eth_platform_data static struct platform_device eth2_device = { .name = MV643XX_ETH_NAME, - .id = 1, + .id = 2, .num_resources = ARRAY_SIZE(mv64x60_eth2_resources), .resource = mv64x60_eth2_resources, .dev = { From ralf@linux-mips.org Fri Feb 9 21:00:17 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 21:00:20 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:12964 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039618AbXBIVAR (ORCPT ); Fri, 9 Feb 2007 21:00:17 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l19L0FtH027035; Fri, 9 Feb 2007 21:00:15 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l19L0EKD027034; Fri, 9 Feb 2007 21:00:14 GMT Date: Fri, 9 Feb 2007 21:00:14 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Atsushi Nemoto , vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Message-ID: <20070209210014.GA26939@linux-mips.org> References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336591652-git-send-email-fbuihuu@gmail.com> <20070210.011835.08318488.anemo@mba.ocn.ne.jp> <61ec3ea90702090834k774bf18bwf7ec5f7b10349779@mail.gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <61ec3ea90702090834k774bf18bwf7ec5f7b10349779@mail.gmail.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14015 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 09, 2007 at 05:34:16PM +0100, Franck Bui-Huu wrote: > Date: Fri, 9 Feb 2007 17:34:16 +0100 > From: "Franck Bui-Huu" > To: "Atsushi Nemoto" > Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel > Cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, > linux-mips@linux-mips.org > Content-Type: text/plain; charset=ISO-8859-1; format=flowed > > On 2/9/07, Atsushi Nemoto wrote: > >On Fri, 9 Feb 2007 16:07:38 +0100, Franck Bui-Huu > >wrote: > >> new_ka.sa.sa_handler = (__sighandler_t) __gu_tmp; > >> > >> Here we try to cast an 'unsigned long long' into a 32 bits pointer and > >> that's the reason of the warning. > > > >This line is never executed on 32bit kernel and gcc optimize out. On > > yes I agree but it seems that gcc compiles this line before optimizing > out... > > > > >I think this is a problem of __get_user() implementation or gcc > >itself. Though I can not find better solution yet, hacking the caller > >to avoid the warning would not be right things to to. > > I agree too but I haven't found something else. All gcc versions produce this warning and no, it's not a gcc bug but a kernel bug. __get_user expands into: case 8: { unsigned long long __gu_tmp; [...] new_ka.sa.sa_handler = (__typeof__(*((&act->sa_handler)))) __gu_tmp; } Which is quite a funny C problem to solve :-) Ralf From stjeanma@pmc-sierra.com Fri Feb 9 21:51:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 21:51:26 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:33765 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039631AbXBIVvU (ORCPT ); Fri, 9 Feb 2007 21:51:20 +0000 Received: (qmail 12738 invoked by uid 101); 9 Feb 2007 21:50:12 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by father.pmc-sierra.com with SMTP; 9 Feb 2007 21:50:12 -0000 Received: from pasqua.pmc-sierra.bc.ca (pasqua.pmc-sierra.bc.ca [134.87.183.161]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l19LoBD1000866; Fri, 9 Feb 2007 13:50:12 -0800 From: Marc St-Jean Received: (from stjeanma@localhost) by pasqua.pmc-sierra.bc.ca (8.13.4/8.12.11) id l19Lo3m0000653; Fri, 9 Feb 2007 15:50:03 -0600 Date: Fri, 9 Feb 2007 15:50:03 -0600 Message-Id: <200702092150.l19Lo3m0000653@pasqua.pmc-sierra.bc.ca> To: linux-serial@vger.kernel.org Subject: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14016 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stjeanma@pmc-sierra.com Precedence: bulk X-list: linux-mips Fifth attempt at the serial driver patch for the PMC-Sierra MSP71xx device. There are three different fixes: 1. Fix for DesignWare THRE errata - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" tree also fixes it. This patch needs to be applied on top of "mm" patch. 2. Fix for Busy Detect on LCR write - Minor formatting changes. 3. Workaround for interrupt/data concurrency issue - No changes since last patch. Sending with /bin/mail, how's that for bare iron... Thanks, Marc Signed-off-by: Marc St-Jean diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 3d91bfc..3362782 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar return inb(up->port.iobase + 1); case UPIO_MEM: + case UPIO_DWAPB: return readb(up->port.membase + offset); case UPIO_MEM32: @@ -333,6 +334,8 @@ #endif static void serial_out(struct uart_8250_port *up, int offset, int value) { + /* Save the offset before it's remapped */ + int save_offset = offset; offset = map_8250_out_reg(up, offset) << up->port.regshift; switch (up->port.iotype) { @@ -359,6 +362,18 @@ #endif writeb(value, up->port.membase + offset); break; + case UPIO_DWAPB: + /* Save the LCR value so it can be re-written when a + * Busy Detect interrupt occurs. */ + if (save_offset == UART_LCR) + up->lcr = value; + writeb(value, up->port.membase + offset); + /* Read the IER to ensure any interrupt is cleared before + * returning from ISR. */ + if ((save_offset == UART_TX || save_offset == UART_IER) && in_irq()) + value = serial_in(up, UART_IER); + break; + default: outb(value, up->port.iobase + offset); } @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u #ifdef CONFIG_SERIAL_8250_AU1X00 case UPIO_AU: #endif + case UPIO_DWAPB: serial_out(up, offset, value); (void)serial_in(up, UART_LCR); /* safe, no side-effects */ break; @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( handled = 1; end = NULL; + } else if (up->port.iotype == UPIO_DWAPB && + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { + /* The DesignWare APB UART has an Busy Detect (0x07) + * interrupt meaning an LCR write attempt occured while the + * UART was busy. The interrupt must be cleared by reading + * the UART status register (USR) and the LCR re-written. */ + unsigned int status; + status = *(volatile u32 *)up->port.private_data; + serial_out(up, UART_LCR, up->lcr); + + handled = 1; + + end = NULL; } else if (end == NULL) end = l; @@ -2085,6 +2114,7 @@ static int serial8250_request_std_resour case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2122,6 +2152,7 @@ static void serial8250_release_std_resou case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2454,8 +2485,8 @@ int __init serial8250_start_console(stru add_preferred_console("ttyS", line, options); printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : + line, port->iotype >= UPIO_MEM ? "MMIO" : "I/O port", + port->iotype >= UPIO_MEM ? (unsigned long) port->mapbase : (unsigned long) port->iobase, options); if (!(serial8250_console.flags & CON_ENABLED)) { serial8250_console.flags &= ~CON_PRINTBUFFER; diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c index f84982e..f5b6036 100644 --- a/drivers/serial/serial_core.c +++ b/drivers/serial/serial_core.c @@ -2057,6 +2057,7 @@ uart_report_port(struct uart_driver *drv case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: snprintf(address, sizeof(address), "MMIO 0x%lx", port->mapbase); break; @@ -2401,6 +2402,7 @@ int uart_match_port(struct uart_port *po case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: return (port1->mapbase == port2->mapbase); } return 0; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index cf23813..8cdd326 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -230,6 +230,7 @@ #define UPIO_MEM (2) #define UPIO_MEM32 (3) #define UPIO_AU (4) /* Au1x00 type IO */ #define UPIO_TSI (5) /* Tsi108/109 type IO */ +#define UPIO_DWAPB (6) /* DesignWare APB UART */ unsigned int read_status_mask; /* driver specific */ unsigned int ignore_status_mask; /* driver specific */ @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( struct device *dev; /* parent device */ unsigned char hub6; /* this should be in the 8250 driver */ unsigned char unused[3]; + void *private_data; /* generic platform data pointer */ }; /* diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 3c8a6aa..1c5ed7d 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -38,6 +38,8 @@ #define UART_IIR_THRI 0x02 /* Transmitt #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ + #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ From djohnson@sw.starentnetworks.com Fri Feb 9 23:48:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 09 Feb 2007 23:48:29 +0000 (GMT) Received: from newmail.sw.starentnetworks.com ([12.33.234.78]:47534 "EHLO mail.sw.starentnetworks.com") by ftp.linux-mips.org with ESMTP id S20039662AbXBIXsY (ORCPT ); Fri, 9 Feb 2007 23:48:24 +0000 Received: from zeus.sw.starentnetworks.com (zeus.sw.starentnetworks.com [12.33.233.46]) by mail.sw.starentnetworks.com (Postfix) with ESMTP id 062B23EEDE for ; Fri, 9 Feb 2007 18:47:39 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17869.2075.900049.547334@zeus.sw.starentnetworks.com> Date: Fri, 9 Feb 2007 18:47:39 -0500 From: Dave Johnson To: linux-mips@linux-mips.org Subject: problems booting sb1250, page fault issue? X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14017 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djohnson+linux-mips@sw.starentnetworks.com Precedence: bulk X-list: linux-mips I've been successfully running 2.6.12 on the sibyte bcm1250 for over a year and have recently been trying to move forward to a more recent kernel. I've got 2.6.18 from linux-mips.org's git tree at the 'linux-2.6.18' TAG built and almost booting. While usually I'd run SMP+PREEMPT, I've turned those off to simplify the kernel. I'm running n64 kernel with o32 userspace. It will run all the way through kernel startup, but once it starts userspace (glibc + sysvinit) things go down hill fast. I replaced init with a statically linked test program that does a few syscalls and then spins to try to track down the issue. When things go wrong the symptom is usually a SIGSEGV or SIGBUS to the process very shortly after it starts running. How far the test program gets varies, but it usually looks like the cpu starts executing incorrect code (at the right address) after returning to userspace from an interrupt/exception. I have two variants of the test 'init' program: 1) once into main() print hello world then branch to self. This program usually works reliably. If the program makes it all the way to the branch to self instruction things are good. The kernel schedules it just fine, taking timer interrupts as expected. 2) once into main() print hello world then call a function that consists of 2MB worth of 'addiu $8,$8,1' instructions then branch to self. Running this program _always_ fails part way through the adds. The program executes through the add instruction and every time it crosses a page boundary it causes a page fault and the kernel loads in the next page from the filesystem as expected. On startup, the program faults in various text, data, and stack pages, and prints Hello World. After this it starts linearly executing add instructions starting at about address 0x00401000. In the below case after about 100KB of add instructions the program takes a SEGV for no apparent reason at 0x00419140! The entire 0x00419000 - 0x00419FFF page should be full of add instructions none of which should cause a SEGV! I enabled some printk's in the page fault handler and I see this: Cpu0[init:1:0000000010004624:1:ffffffff8025f438] Cpu0[init:1:0000000000400190:0:0000000000400190] Cpu0[init:1:0000000010003f70:0:00000000004001e0] Cpu0[init:1:0000000000604670:0:0000000000604670] Cpu0[init:1:00000000100004f4:0:00000000006046f4] Cpu0[init:1:0000000010000550:1:0000000000604718] Cpu0[init:1:000000000060e380:0:000000000060e380] Cpu0[init:1:0000000000619890:0:0000000000619890] Cpu0[init:1:000000000062c028:0:000000000062c028] Cpu0[init:1:000000000061fd70:0:000000000061fd70] Cpu0[init:1:0000000010002f80:0:000000000061998c] Cpu0[init:1:0000000000618e10:0:0000000000618e10] Cpu0[init:1:0000000000620c50:0:0000000000620c50] Cpu0[init:1:000000000062ad20:0:000000000062ad20] Cpu0[init:1:0000000000679b74:0:000000000062ad78] Cpu0[init:1:000000000060fb40:0:000000000060fb40] Cpu0[init:1:0000000000606b24:0:0000000000606b24] Cpu0[init:1:0000000000605d20:0:0000000000605d20] Cpu0[init:1:0000000000607010:0:0000000000607010] Cpu0[init:1:000000000060c7f0:0:000000000060c7f0] Cpu0[init:1:0000000010006004:1:0000000000607894] Cpu0[init:1:0000000000610528:0:0000000000610528] Cpu0[init:1:000000000062e490:0:000000000062e490] Cpu0[init:1:0000000000678c30:0:0000000000678c30] Hello World! Cpu0[init:1:0000000000401000:0:0000000000401000] Cpu0[init:1:0000000000402000:0:0000000000402000] Cpu0[init:1:0000000000403000:0:0000000000403000] Cpu0[init:1:0000000000404000:0:0000000000404000] Cpu0[init:1:0000000000405000:0:0000000000405000] Cpu0[init:1:0000000000406000:0:0000000000406000] Cpu0[init:1:0000000000407000:0:0000000000407000] Cpu0[init:1:0000000000408000:0:0000000000408000] Cpu0[init:1:0000000000409000:0:0000000000409000] Cpu0[init:1:000000000040a000:0:000000000040a000] Cpu0[init:1:000000000040b000:0:000000000040b000] Cpu0[init:1:000000000040c000:0:000000000040c000] Cpu0[init:1:000000000040d000:0:000000000040d000] Cpu0[init:1:000000000040e000:0:000000000040e000] Cpu0[init:1:000000000040f000:0:000000000040f000] Cpu0[init:1:0000000000410000:0:0000000000410000] Cpu0[init:1:0000000000411000:0:0000000000411000] Cpu0[init:1:0000000000412000:0:0000000000412000] Cpu0[init:1:0000000000413000:0:0000000000413000] Cpu0[init:1:0000000000414000:0:0000000000414000] Cpu0[init:1:0000000000415000:0:0000000000415000] Cpu0[init:1:0000000000416000:0:0000000000416000] Cpu0[init:1:0000000000417000:0:0000000000417000] Cpu0[init:1:0000000000418000:0:0000000000418000] Cpu0[init:1:0000000000419000:0:0000000000419000] Cpu0[init:1:0000000000000098:1:0000000000419140] do_page_fault() #2: sending SIGSEGV to init for invalid write access to 0000000000000098 (epc == 0000000000419140, ra == 00000000006045b8) Cpu0[init:1:0000000000000098:1:0000000000419140] do_page_fault() #2: sending SIGSEGV to init for invalid write access to 0000000000000098 (epc == 0000000000419140, ra == 00000000006045b8) Cpu0[init:1:0000000000000098:1:0000000000419140] do_page_fault() #2: sending SIGSEGV to init for invalid write access to 0000000000000098 (epc == 0000000000419140, ra == 00000000006045b8) Cpu0[init:1:0000000000000098:1:0000000000419140] do_page_fault() #2: sending SIGSEGV to init for invalid write access to 0000000000000098 (epc == 0000000000419140, ra == 00000000006045b8) Cpu0[init:1:0000000000000098:1:0000000000419140] do_page_fault() #2: sending SIGSEGV to init for invalid write access to 0000000000000098 (epc == 0000000000419140, ra == 00000000006045b8) Cpu0[init:1:0000000000000098:1:0000000000419140] I've carefully gone through syscall and interrupt/exception entry/exit with a jtag debugger to make sure registers are saved/restored correctly and everything looks fine at least on the few times I walked through it. After taking the fault, I also examined the page that took the fault and verified it is full of 'addiu $8,$8,1' including the instruction that the kernel thinks a SEGV occurred on. Since the page contains correct data, I tried adding gratuitous icache flushes after each page fault before returning to userspace to rule out any issues there, but with no help. Has issues like this been seen before? If not, does anyone have ideas that I could try next? -- Dave Johnson Starent Networks From andy.sharp@onstor.com Sat Feb 10 01:27:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 01:27:31 +0000 (GMT) Received: from [66.201.51.66] ([66.201.51.66]:19735 "EHLO ripper.onstor.net") by ftp.linux-mips.org with ESMTP id S20039654AbXBJB10 (ORCPT ); Sat, 10 Feb 2007 01:27:26 +0000 Received: from andys by ripper.onstor.net with local (Exim 4.63) (envelope-from ) id 1HFgyJ-0003al-5a for linux-mips@linux-mips.org; Fri, 09 Feb 2007 17:24:11 -0800 Date: Fri, 9 Feb 2007 17:24:11 -0800 From: tigerand@gmail.com To: linux-mips@linux-mips.org Subject: [PATCH] Fix non-SMP build Sibyte 1250 SOC, kernel linux-mips.git master Message-ID: <20070210012404.GA13779@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14018 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tigerand@gmail.com Precedence: bulk X-list: linux-mips Fix build of non-SMP for Sibyte 1250 SOC Signed off by: Andrew Sharp diff --git a/arch/mips/mm/c-sb1.c b/arch/mips/mm/c-sb1.c index 9ea460b..3a8afd4 100644 --- a/arch/mips/mm/c-sb1.c +++ b/arch/mips/mm/c-sb1.c @@ -259,12 +259,6 @@ static void sb1_flush_cache_data_page(unsigned long addr) on_each_cpu(sb1_flush_cache_data_page_ipi, (void *) addr, 1, 1); } #else - -static void local_sb1_flush_cache_data_page(unsigned long addr) -{ - __sb1_writeback_inv_dcache_range(addr, addr + PAGE_SIZE); -} - void sb1_flush_cache_data_page(unsigned long) __attribute__((alias("local_sb1_flush_cache_data_page"))); #endif From andy.sharp@onstor.com Sat Feb 10 01:35:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 01:35:38 +0000 (GMT) Received: from [66.201.51.66] ([66.201.51.66]:14872 "EHLO ripper.onstor.net") by ftp.linux-mips.org with ESMTP id S20039649AbXBJBfd (ORCPT ); Sat, 10 Feb 2007 01:35:33 +0000 Received: from andys by ripper.onstor.net with local (Exim 4.63) (envelope-from ) id 1HFh9E-0003dP-29 for linux-mips@linux-mips.org; Fri, 09 Feb 2007 17:35:28 -0800 Date: Fri, 9 Feb 2007 17:35:28 -0800 From: tigerand@gmail.com To: linux-mips@linux-mips.org Subject: [PATCH] try#2 Fix non-SMP build Sibyte 1250 SOC, kernel linux-mips.git master Message-ID: <20070210013521.GA13917@onstor.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.5.13 (2006-08-11) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14019 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tigerand@gmail.com Precedence: bulk X-list: linux-mips Try #2, sorry, first patch was reversed. Fix build of non-SMP for Sibyte 1250 SOC Signed-off-by: Andrew Sharp diff --git a/arch/mips/mm/c-sb1.c b/arch/mips/mm/c-sb1.c index 3a8afd4..9ea460b 100644 --- a/arch/mips/mm/c-sb1.c +++ b/arch/mips/mm/c-sb1.c @@ -259,6 +259,12 @@ static void sb1_flush_cache_data_page(unsigned long addr) on_each_cpu(sb1_flush_cache_data_page_ipi, (void *) addr, 1, 1); } #else + +static void local_sb1_flush_cache_data_page(unsigned long addr) +{ + __sb1_writeback_inv_dcache_range(addr, addr + PAGE_SIZE); +} + void sb1_flush_cache_data_page(unsigned long) __attribute__((alias("local_sb1_flush_cache_data_page"))); #endif From clem.taylor@gmail.com Sat Feb 10 02:54:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 02:54:37 +0000 (GMT) Received: from ug-out-1314.google.com ([66.249.92.169]:35541 "EHLO ug-out-1314.google.com") by ftp.linux-mips.org with ESMTP id S20039671AbXBJCyd (ORCPT ); Sat, 10 Feb 2007 02:54:33 +0000 Received: by ug-out-1314.google.com with SMTP id 40so100573uga for ; Fri, 09 Feb 2007 18:53:32 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=UkYZZuIpgZR4Ry/237G0g7uzIlsLhl3AmWdAMeyWXA8cCXFmB/MIFt8jgC6AWt2QcVkUilr7j9BvFezblOJURQIlP0Y/9qeO29S6nH1Koizl5eu6Moi4boGghgGovv7ZoEv5lKXScujmj/Uet+URuAi6tRcdDyB5+6RWxeVB7us= Received: by 10.78.181.13 with SMTP id d13mr65586huf.1171076010210; Fri, 09 Feb 2007 18:53:30 -0800 (PST) Received: by 10.78.170.9 with HTTP; Fri, 9 Feb 2007 18:53:30 -0800 (PST) Message-ID: Date: Fri, 9 Feb 2007 21:53:30 -0500 From: "Clem Taylor" To: linux-mips@linux-mips.org Subject: PCI troubles on Alchemy AU1550 in 2.6.20 (and 2.6.19.1) MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14020 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: clem.taylor@gmail.com Precedence: bulk X-list: linux-mips Hi, I was wondering if anyone has any PCI devices working on an AU1550 with 2.6.20 or 2.6.19.1. I'm currently using 2.6.16.16 and I've been trying to move to 2.6.20. With 2.6.19.1 (including the resource_size_t patch) and 2.6.20, reading from an address that is mapped with ioremap_nocache() is returning the wrong data. I also tried out the sata_sil driver which was working with 2.6.16.1, but with 2.6.20 it seems unhappy: sata_sil 0000:00:13.0: version 2.0 PCI: Enabling device 0000:00:13.0 (0000 -> 0003) sata_sil 0000:00:13.0: cache line size not set. Driver may not function PCI: Setting latency timer of device 0000:00:13.0 to 64 ata1: SATA max UDMA/100 cmd 0xC0102080 ctl 0xC010208A bmdma 0xC0102000 irq 1 ata2: SATA max UDMA/100 cmd 0xC01020C0 ctl 0xC01020CA bmdma 0xC0102008 irq 1 scsi0 : sata_sil ata1: SATA link up (SStatus 208 SControl 2484F5B8) scsi1 : sata_sil ata2: SATA link up (SStatus 1000FC08 SControl 2484F5B8) It doesn't seem to be finding the disk. With 2.6.16.16 it is happy: libata version 1.20 loaded. sata_sil 0000:00:13.0: version 0.9 PCI: Enabling device 0000:00:13.0 (0000 -> 0003) sata_sil 0000:00:13.0: cache line size not set. Driver may not function sata_sil 0000:00:13.0: Applying R_ERR on DMA activate FIS errata fix PCI: Setting latency timer of device 0000:00:13.0 to 64 ata1: SATA max UDMA/100 cmd 0xC0162080 ctl 0xC016208A bmdma 0xC0162000 irq 1 ata2: SATA max UDMA/100 cmd 0xC01620C0 ctl 0xC01620CA bmdma 0xC0162008 irq 1 ata1: SATA link down (SStatus 0) scsi0 : sata_sil ata2: SATA link up 1.5 Gbps (SStatus 113) ata2: dev 0 cfg 49:2f00 82:346b 83:7d01 84:4023 85:3469 86:3c01 87:4023 88:207f ata2: dev 0 ATA-7, max UDMA/133, 1465149168 sectors: LBA48 ata2: dev 0 configured for UDMA/100 scsi1 : sata_sil Vendor: ATA Model: ST3750640AS Rev: 3.AA Type: Direct-Access ANSI SCSI revision: 05 SCSI device sda: 1465149168 512-byte hdwr sectors (750156 MB) ... If I define CONFIG_RESOURCES_64BIT, then things get even worse, none of the PCI devices show up. This would agree with what Alexander Bigga saw without the resource_size_t fixups. I applied his patch to 2.6.19.1 and it seems to be in 2.6.20. Any ideas? Clem From heiko.carstens@de.ibm.com Sat Feb 10 10:24:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 10:24:25 +0000 (GMT) Received: from mtagate6.de.ibm.com ([195.212.29.155]:59957 "EHLO mtagate6.de.ibm.com") by ftp.linux-mips.org with ESMTP id S20037476AbXBJKYU (ORCPT ); Sat, 10 Feb 2007 10:24:20 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate6.de.ibm.com (8.13.8/8.13.8) with ESMTP id l1AANE5g036144; Sat, 10 Feb 2007 10:23:14 GMT Received: from d12av03.megacenter.de.ibm.com (d12av03.megacenter.de.ibm.com [9.149.165.213]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1AANEdN1384540; Sat, 10 Feb 2007 11:23:14 +0100 Received: from d12av03.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1AANEPW027364; Sat, 10 Feb 2007 11:23:14 +0100 Received: from localhost (dyn-9-152-198-88.boeblingen.de.ibm.com [9.152.198.88]) by d12av03.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1AANEjR027361; Sat, 10 Feb 2007 11:23:14 +0100 Date: Sat, 10 Feb 2007 11:22:05 +0100 From: Heiko Carstens To: Davide Libenzi , ralf@linux-mips.org, linux-mips@linux-mips.org Cc: David Woodhouse , Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 Message-ID: <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: mutt-ng/devel-r804 (Linux) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14021 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: heiko.carstens@de.ibm.com Precedence: bulk X-list: linux-mips On Fri, Feb 09, 2007 at 02:50:12PM -0800, Davide Libenzi wrote: > On Fri, 9 Feb 2007, David Woodhouse wrote: > > > On Fri, 2007-02-09 at 13:45 -0800, Andrew Morton wrote: > > > > I would strongly recommend that in the general case, you don't merge new > > > > system calls unless the corresponding compat_ system call is > > > > implemented. > > > > > > Good point. > > > > It's a _damn_ good point, but I see we went ahead and merged > > sys_epoll_pwait without it anyway -- despite the fact that it's > > include/linux/eventpoll.h which contains the example of why we should > > think first :) > > > > I think I even threw together an untested implementation of > > compat_sys_epoll_pwait() at one point to assist with that task, but it > > didn't seem to help much. > > Damn! I always forget. Doing it right now ... Which remembers me that I think that MIPS is using the non-compat version of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat syscall for some reason. Dunno. From thomas.koeller@baslerweb.com Sat Feb 10 10:26:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 10:26:40 +0000 (GMT) Received: from mail02.hansenet.de ([213.191.73.62]:50107 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20037543AbXBJK0f (ORCPT ); Sat, 10 Feb 2007 10:26:35 +0000 Received: from [213.39.184.171] (213.39.184.171) by webmail.hansenet.de (7.2.074) (authenticated as mbx20228207@koeller-hh.org) id 45CB2B4F000CF39F; Sat, 10 Feb 2007 11:22:44 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id 1E3BC479FC; Sat, 10 Feb 2007 11:22:43 +0100 (CET) From: Thomas Koeller Organization: Basler AG To: Thomas Gleixner Subject: Re: [PATCH] eXcite nand flash driver Date: Sat, 10 Feb 2007 11:22:04 +0100 User-Agent: KMail/1.9.6 Cc: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org References: <200702080157.25432.thomas.koeller@baslerweb.com> <1170949737.3646.29.camel@chaos> In-Reply-To: <1170949737.3646.29.camel@chaos> MIME-Version: 1.0 Content-Disposition: inline Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Message-Id: <200702101122.05049.thomas.koeller@baslerweb.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14022 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips On Donnerstag, 8. Februar 2007, Thomas Gleixner wrote: > > +/* command and control functions */ > > +static void excite_nand_control(struct mtd_info *mtd, int cmd, > > + unsigned int ctrl) > > +{ > > + io_reg_t regs = > > + container_of(mtd, struct excite_nand_drvdata, board_mtd)->regs; > > + static void __iomem *tgt = NULL; > > + > > + switch (ctrl) { > > + case NAND_CTRL_CHANGE | NAND_CTRL_CLE: > > + tgt = regs + EXCITE_NANDFLASH_CMD_BYTE; > > + break; > > + case NAND_CTRL_CHANGE | NAND_CTRL_ALE: > > + tgt = regs + EXCITE_NANDFLASH_ADDR_BYTE; > > + break; > > + case NAND_CTRL_CHANGE | NAND_NCE: > > + tgt = regs + EXCITE_NANDFLASH_DATA_BYTE; > > + break; > > + } > > Err, did this ever work ? I doubt it. From nand_base.c: > > chip->cmd_ctrl(mtd, page_addr, ctrl); > ctrl &= ~NAND_CTRL_CHANGE; > chip->cmd_ctrl(mtd, page_addr >> 8, ctrl); > > So I expect an OOPS happens on a regular base. > I guess it is the 'static void __iomem *tgt = NULL' part that worries you? Think about it, that value is never used. However, I admit it is somewhat unclean, and therefore I am changing it. Updated patch follows. tk From thomas.koeller@baslerweb.com Sat Feb 10 10:27:03 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 10:27:07 +0000 (GMT) Received: from mail02.hansenet.de ([213.191.73.62]:50363 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20038938AbXBJK0l (ORCPT ); Sat, 10 Feb 2007 10:26:41 +0000 Received: from [213.39.184.171] (213.39.184.171) by webmail.hansenet.de (7.2.074) (authenticated as mbx20228207@koeller-hh.org) id 45CB2B4F000CF3A0; Sat, 10 Feb 2007 11:22:44 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id DD78C479CA; Sat, 10 Feb 2007 11:22:42 +0100 (CET) From: Thomas Koeller Date: Sat, 10 Feb 2007 11:21:27 +0100 Subject: [PATCH] eXcite nand flash driver X-Length: 9376 X-UID: 3 To: linux-mtd@lists.infradead.org Cc: linux-mips@linux-mips.org MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline Message-Id: <200702101121.28138.thomas.koeller@baslerweb.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14023 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips This is a nand flash driver for the eXcite series of intelligent cameras manufactured by Basler Vision Technologies AG. Signed-off-by: Thomas Koeller =2D-- drivers/mtd/nand/Kconfig | 8 + drivers/mtd/nand/Makefile | 1 + drivers/mtd/nand/excite_nandflash.c | 248=20 +++++++++++++++++++++++++++++++++++ 3 files changed, 257 insertions(+), 0 deletions(-) diff --git a/drivers/mtd/nand/Kconfig b/drivers/mtd/nand/Kconfig index 358f55a..d188263 100644 =2D-- a/drivers/mtd/nand/Kconfig +++ b/drivers/mtd/nand/Kconfig @@ -221,6 +221,14 @@ config MTD_NAND_SHARPSL tristate "Support for NAND Flash on Sharp SL Series (C7xx + others)" depends on MTD_NAND && ARCH_PXA =20 +config MTD_NAND_BASLER_EXCITE + tristate "Support for NAND Flash on Basler eXcite" + depends on MTD_NAND && BASLER_EXCITE + help + This enables the driver for the NAND flash device found on the + Basler eXcite Smart Camera. If built as a module, the driver + will be named "excite_nandflash.ko". + config MTD_NAND_CAFE tristate "NAND support for OLPC CAF=C9 chip" depends on PCI diff --git a/drivers/mtd/nand/Makefile b/drivers/mtd/nand/Makefile index f7a53f0..80f1dfc 100644 =2D-- a/drivers/mtd/nand/Makefile +++ b/drivers/mtd/nand/Makefile @@ -24,6 +24,7 @@ obj-$(CONFIG_MTD_NAND_NANDSIM) +=3D nands obj-$(CONFIG_MTD_NAND_CS553X) +=3D cs553x_nand.o obj-$(CONFIG_MTD_NAND_NDFC) +=3D ndfc.o obj-$(CONFIG_MTD_NAND_AT91) +=3D at91_nand.o +obj-$(CONFIG_MTD_NAND_BASLER_EXCITE) +=3D excite_nandflash.o =20 nand-objs :=3D nand_base.o nand_bbt.o cafe_nand-objs :=3D cafe.o cafe_ecc.o diff --git a/drivers/mtd/nand/excite_nandflash.c=20 b/drivers/mtd/nand/excite_nandflash.c new file mode 100644 index 0000000..7e9afc4 =2D-- /dev/null +++ b/drivers/mtd/nand/excite_nandflash.c @@ -0,0 +1,248 @@ +/* +* Copyright (C) 2005 - 2007 by Basler Vision Technologies AG +* Author: Thomas Koeller +* Original code by Thies Moeller +* +* This program is free software; you can redistribute it and/or modify +* it under the terms of the GNU General Public License as published by +* the Free Software Foundation; either version 2 of the License, or +* (at your option) any later version. +* +* This program is distributed in the hope that it will be useful, +* but WITHOUT ANY WARRANTY; without even the implied warranty of +* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +* GNU General Public License for more details. +* +* You should have received a copy of the GNU General Public License +* along with this program; if not, write to the Free Software +* Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 U= SA +*/ + +#include +#include +#include +#include +#include +#include +#include +#include +#include +#include + +#include +#include +#include +#include + +#include +#include + +#include + +#define EXCITE_NANDFLASH_VERSION "0.1" + +/* I/O register offsets */ +#define EXCITE_NANDFLASH_DATA_BYTE 0x00 +#define EXCITE_NANDFLASH_STATUS_BYTE 0x0c +#define EXCITE_NANDFLASH_ADDR_BYTE 0x10 +#define EXCITE_NANDFLASH_CMD_BYTE 0x14 + +/* prefix for debug output */ +static const char module_id[] =3D "excite_nandflash"; + +/* + * partition definition + */ +static const struct mtd_partition partition_info[] =3D { + { + .name =3D "eXcite RootFS", + .offset =3D 0, + .size =3D MTDPART_SIZ_FULL + } +}; + +static inline const struct resource * +excite_nand_get_resource(struct platform_device *d, unsigned long flags, + const char *basename) +{ + char buf[80]; + + if (snprintf(buf, sizeof buf, "%s_%u", basename, d->id) >=3D sizeof buf) + return NULL; + return platform_get_resource_byname(d, flags, buf); +} + +static inline void __iomem * +excite_nand_map_regs(struct platform_device *d, const char *basename) +{ + void *result =3D NULL; + const struct resource *const r =3D + excite_nand_get_resource(d, IORESOURCE_MEM, basename); + + if (r) + result =3D ioremap_nocache(r->start, r->end + 1 - r->start); + return result; +} + +/* controller and mtd information */ +struct excite_nand_drvdata { + struct mtd_info board_mtd; + struct nand_chip board_chip; + void __iomem *regs; + void __iomem *tgt; +}; + +/* Control function */ +static void excite_nand_control(struct mtd_info *mtd, int cmd, + unsigned int ctrl) +{ + struct excite_nand_drvdata * const d =3D + container_of(mtd, struct excite_nand_drvdata, board_mtd); + + switch (ctrl) { + case NAND_CTRL_CHANGE | NAND_CTRL_CLE: + d->tgt =3D d->regs + EXCITE_NANDFLASH_CMD_BYTE; + break; + case NAND_CTRL_CHANGE | NAND_CTRL_ALE: + d->tgt =3D d->regs + EXCITE_NANDFLASH_ADDR_BYTE; + break; + case NAND_CTRL_CHANGE | NAND_NCE: + d->tgt =3D d->regs + EXCITE_NANDFLASH_DATA_BYTE; + break; + } + + if (cmd !=3D NAND_CMD_NONE) + __raw_writeb(cmd, d->tgt); +} + +/* Return 0 if flash is busy, 1 if ready */ +static int excite_nand_devready(struct mtd_info *mtd) +{ + struct excite_nand_drvdata * const drvdata =3D + container_of(mtd, struct excite_nand_drvdata, board_mtd); + + return __raw_readb(drvdata->regs + EXCITE_NANDFLASH_STATUS_BYTE); +} + +/* + * Called by device layer to remove the driver. + * The binding to the mtd and all allocated + * resources are released. + */ +static int __exit excite_nand_remove(struct device *dev) +{ + struct excite_nand_drvdata * const this =3D dev_get_drvdata(dev); + + dev_set_drvdata(dev, NULL); + + if (unlikely(!this)) { + printk(KERN_ERR "%s: called %s without private data!!", + module_id, __func__); + return -EINVAL; + } + + /* first thing we need to do is release our mtd + * then go through freeing the resource used + */ + nand_release(&this->board_mtd); + + /* free the common resources */ + iounmap(this->regs); + kfree(this); + + DEBUG(MTD_DEBUG_LEVEL1, "%s: removed\n", module_id); + return 0; +} + +/* + * Called by device layer when it finds a device matching + * one our driver can handle. This code checks to see if + * it can allocate all necessary resources then calls the + * nand layer to look for devices. +*/ +static int __init excite_nand_probe(struct device *dev) +{ + struct platform_device * const pdev =3D to_platform_device(dev); + struct excite_nand_drvdata *drvdata; /* private driver data */ + struct nand_chip *board_chip; /* private flash chip data */ + struct mtd_info *board_mtd; /* mtd info for this board */ + int scan_res; + + drvdata =3D kzalloc(sizeof(*drvdata), GFP_KERNEL); + if (unlikely(!drvdata)) { + printk(KERN_ERR "%s: no memory for drvdata\n", + module_id); + return -ENOMEM; + } + + /* bind private data into driver */ + dev_set_drvdata(dev, drvdata); + + /* allocate and map the resource */ + drvdata->regs =3D + excite_nand_map_regs(pdev, EXCITE_NANDFLASH_RESOURCE_REGS); + + if (unlikely(!drvdata->regs)) { + printk(KERN_ERR "%s: cannot reserve register region\n", + module_id); + kfree(drvdata); + return -ENXIO; + } +=09 + drvdata->tgt =3D drvdata->regs + EXCITE_NANDFLASH_DATA_BYTE; + + /* initialise our chip */ + board_chip =3D &drvdata->board_chip; + board_chip->IO_ADDR_R =3D board_chip->IO_ADDR_W =3D + drvdata->regs + EXCITE_NANDFLASH_DATA_BYTE; + board_chip->cmd_ctrl =3D excite_nand_control; + board_chip->dev_ready =3D excite_nand_devready; + board_chip->chip_delay =3D 25; + board_chip->ecc.mode =3D NAND_ECC_SOFT; + + /* link chip to mtd */ + board_mtd =3D &drvdata->board_mtd; + board_mtd->priv =3D board_chip; + + DEBUG(MTD_DEBUG_LEVEL2, "%s: device scan\n", module_id); + scan_res =3D nand_scan(&drvdata->board_mtd, 1); + + if (likely(!scan_res)) { + DEBUG(MTD_DEBUG_LEVEL2, "%s: register partitions\n", module_id); + add_mtd_partitions(&drvdata->board_mtd, partition_info, + sizeof partition_info / sizeof partition_info[0]); + } else { + iounmap(drvdata->regs); + kfree(drvdata); + printk(KERN_ERR "%s: device scan failed\n", module_id); + return -EIO; + } + return 0; +} + +static struct device_driver excite_nand_driver =3D { + .name =3D "excite_nand", + .bus =3D &platform_bus_type, + .probe =3D excite_nand_probe, + .remove =3D __exit_p(excite_nand_remove) +}; + +static int __init excite_nand_init(void) +{ + pr_info("Basler eXcite nand flash driver Version " + EXCITE_NANDFLASH_VERSION "\n"); + return driver_register(&excite_nand_driver); +} + +static void __exit excite_nand_exit(void) +{ + driver_unregister(&excite_nand_driver); +} + +module_init(excite_nand_init); +module_exit(excite_nand_exit); + +MODULE_AUTHOR("Thomas Koeller "); +MODULE_DESCRIPTION("Basler eXcite NAND-Flash driver"); +MODULE_LICENSE("GPL"); +MODULE_VERSION(EXCITE_NANDFLASH_VERSION) =2D-=20 1.4.3 From SRS0+5cffa4984f8ae9ed5307+1266+infradead.org+dwmw2@pentafluge.srs.infradead.org Sat Feb 10 10:35:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 10:35:37 +0000 (GMT) Received: from pentafluge.infradead.org ([213.146.154.40]:34998 "EHLO pentafluge.infradead.org") by ftp.linux-mips.org with ESMTP id S20038938AbXBJKfc (ORCPT ); Sat, 10 Feb 2007 10:35:32 +0000 Received: from pmac.infradead.org ([81.187.2.168]) by pentafluge.infradead.org with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1HFpWd-0005St-7l; Sat, 10 Feb 2007 10:32:11 +0000 Subject: Re: -mm merge plans for 2.6.21 From: David Woodhouse To: Heiko Carstens Cc: Davide Libenzi , ralf@linux-mips.org, linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper In-Reply-To: <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> Content-Type: text/plain Date: Sat, 10 Feb 2007 10:32:07 +0000 Message-Id: <1171103527.29713.228.camel@pmac.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14024 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: linux-mips On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree there there's 32 bits of padding between the fields of this structure: struct epoll_event { __u32 events; __u64 data; }; I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 ABI is different then it would need the compat syscall. -- dwmw2 From anemo@mba.ocn.ne.jp Sat Feb 10 15:41:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 15:41:49 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:63686 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039014AbXBJPln (ORCPT ); Sat, 10 Feb 2007 15:41:43 +0000 Received: from localhost (p3173-ipad210funabasi.chiba.ocn.ne.jp [58.88.122.173]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id AC917B89B; Sun, 11 Feb 2007 00:40:20 +0900 (JST) Date: Sun, 11 Feb 2007 00:40:20 +0900 (JST) Message-Id: <20070211.004020.79071872.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] clean up ret_from_{irq,exception} From: Atsushi Nemoto In-Reply-To: <45C8A477.8070906@innova-card.com> References: <45C8A477.8070906@innova-card.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14025 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Tue, 06 Feb 2007 16:53:27 +0100, Franck Bui-Huu wrote: > This patch makes these routines a lot more readable whatever > the value of CONFIG_PREEMPT. > > It also moves one branch instruction from ret_from_irq() > to ret_from_exception(). Therefore we favour the return > from irq path which should be more common than the other > one. After this patch, entry.S becomes: FEXPORT(ret_from_exception) #ifndef CONFIG_PREEMPT local_irq_disable # preempt stop #endif b _ret_from_irq FEXPORT(ret_from_irq) LONG_S s0, TI_REGS($28) FEXPORT(_ret_from_irq) Apparently your patch add an additional branch in critical path in CONFIG_PREEMPT=y case. Maybe this would be better? #ifdef CONFIG_PREEMPT FEXPORT(ret_from_irq) LONG_S s0, TI_REGS($28) FEXPORT(ret_from_exception) #else FEXPORT(ret_from_exception) local_irq_disable # preempt stop b _ret_from_irq FEXPORT(ret_from_irq) LONG_S s0, TI_REGS($28) #endif FEXPORT(_ret_from_irq) --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Sat Feb 10 16:04:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 16:05:03 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:25800 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20037425AbXBJQE4 (ORCPT ); Sat, 10 Feb 2007 16:04:56 +0000 Received: from localhost (p3173-ipad210funabasi.chiba.ocn.ne.jp [58.88.122.173]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 854DAB8DB; Sun, 11 Feb 2007 01:03:36 +0900 (JST) Date: Sun, 11 Feb 2007 01:03:36 +0900 (JST) Message-Id: <20070211.010336.15248113.anemo@mba.ocn.ne.jp> To: djohnson+linux-mips@sw.starentnetworks.com Cc: linux-mips@linux-mips.org Subject: Re: problems booting sb1250, page fault issue? From: Atsushi Nemoto In-Reply-To: <17869.2075.900049.547334@zeus.sw.starentnetworks.com> References: <17869.2075.900049.547334@zeus.sw.starentnetworks.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14026 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Fri, 9 Feb 2007 18:47:39 -0500, Dave Johnson wrote: > I've got 2.6.18 from linux-mips.org's git tree at the 'linux-2.6.18' > TAG built and almost booting. You mean 2.6.18 is OK and more recent kernel has problem? Or 2.6.18 has problem? > After taking the fault, I also examined the page that took the > fault and verified it is full of 'addiu $8,$8,1' including the > instruction that the kernel thinks a SEGV occurred on. > > Since the page contains correct data, I tried adding gratuitous icache > flushes after each page fault before returning to userspace to rule > out any issues there, but with no help. > > Has issues like this been seen before? If not, does anyone have ideas > that I could try next? Is this problem still happen in 2.6.20? Please refer this thread: http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=710F16C36810444CA2F5821E5EAB7F230A0DFA%40NT-SJCA-0752.brcm.ad.broadcom.com --- Atsushi Nemoto From thomas@koeller.dyndns.org Sat Feb 10 16:15:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 16:16:02 +0000 (GMT) Received: from mail02.hansenet.de ([213.191.73.62]:35022 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20039020AbXBJQP4 (ORCPT ); Sat, 10 Feb 2007 16:15:56 +0000 Received: from [213.39.184.171] (213.39.184.171) by webmail.hansenet.de (7.2.074) (authenticated as mbx20228207@koeller-hh.org) id 45CB2B4F000EC08F; Sat, 10 Feb 2007 17:11:48 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id 4B2FC479CA; Sat, 10 Feb 2007 17:11:47 +0100 (CET) From: Thomas Koeller To: Sergei Shtylyov Subject: Re: [PATCH] RM9000 serial driver Date: Sat, 10 Feb 2007 17:11:46 +0100 User-Agent: KMail/1.9.6 Cc: Russell King , linux-serial@vger.kernel.org, ralf@linux-mips.org, linux-mips@linux-mips.org References: <200608102318.52143.thomas.koeller@baslerweb.com> <20060830121216.GA25699@flint.arm.linux.org.uk> <44F5C1BB.7010205@ru.mvista.com> In-Reply-To: <44F5C1BB.7010205@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702101711.46826.thomas@koeller.dyndns.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14027 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas@koeller.dyndns.org Precedence: bulk X-list: linux-mips On Mittwoch, 30. August 2006, Sergei Shtylyov wrote: > > Russell King wrote: > >>I would like to return to the port type vs. iotype stuff once again. > > > >From what you wrote I seem to understand that the iotype is not just > > > >>a method of accessing device registers, but also the primary means of > >>discrimination between different h/w implementations, and hence every > >>code to support a nonstandard device must define an iotype of its own, > >>even though one of the existing iotypes would work just fine? > > > > iotype is all about the access method used to access the registers of > > the device, be it by byte or word, and it also takes account of any > > variance in the addressing of the registers. > > > > It does not refer to features or bugs in any particular implementation. > > Well, the introduction of the UPIO_TSI case seems to contradict this -- > it's exactly about the bugs in the particular UART implementation > (otherwise well described by UPIO_MEM). Its only function was to mask 2 > hardware issues. And the UUE bit workaround seems like an abuse to me. The > driver could just skip the UUE test altogether based on iotype == UPIO_TSI > (or at least not to ignore writes with UUE set completely like it does but > just mask off UUE bit). With no provision to pass the implicit UART type > for platform devices (and skip the autoconfiguation), the introduction of > UPIO_TSI seems again the necessary evil. Otherwise, we could have this > handled with a distinct TSI UART type... > > WBR, Sergei Hi, after a long delay (for which I apologize) I would like to return to this topic. Since so much time has passed since the discussion ceased, I think I should summarize its state at that point: 1. In the RM9000 serial driver patch I submitted, I had introduced a new port type PORT_RM9000. I set the iotype to UPIO_MEM32. Wherever I needed to handle any peculiarities of the RM9000 h/w, I did so based upon the port type. AFAICT this is in agreement with Russel's view as quoted above. 2. Sergei says this is wrong, I need to introduce a new iotype instead, and make the code conditional upon that, like the AU1000 does (UPIO_AU). The reason he gives (see quote above) is that there is no way to pass the port type along with a platform device. Is this argument still valid? What about including the port type in the information attached to platform_device.platform_data? Btw., I had a look ath the existing code dealing with platform devices. Is there a particular reason for not using the standard platform_device.resource mechanism of passing mem/io/irq resources from the platform to the driver? Another topic discussed was the use (or abuse) of dl_serial_read()/ dl_serial_write() to get/set the divisor registers. 3. Russel says (qoute from an earlier mail), > It's worse than that - this code is there to read the ID from the divisor > registers implemented in some UARTs. If it isn't one of those UARTs, > it's expected to return zero. 4. I followed the AU1X00 code in this case, using the functions to read/write the divisor value. My hardware has its UART_DLL and UART_DLM registers at nonstandard addresses, and so the only other option would have been to monitor every write to the LCR register for setting or clearing the DLAB bit, and to switch between different mapping tables accordingly. In the light of this, would it still be unacceptable to use the dl_*() functions tho access the divisor registers? Once these issues have been resolved, I will submit an updated version of my patch. tk -- Thomas Koeller thomas@koeller.dyndns.org From sshtylyov@ru.mvista.com Sat Feb 10 17:30:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 17:30:46 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:15089 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037424AbXBJRal (ORCPT ); Sat, 10 Feb 2007 17:30:41 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 74BBF3EC9; Sat, 10 Feb 2007 09:30:05 -0800 (PST) Message-ID: <45CE0119.9060401@ru.mvista.com> Date: Sat, 10 Feb 2007 20:30:01 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Marc St-Jean Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er References: <45CCCDD4.7030104@pmc-sierra.com> In-Reply-To: <45CCCDD4.7030104@pmc-sierra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14028 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Marc St-Jean wrote: >> > Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx >>device. >> > There are three different fixes: >> > 1. Fix for DesignWare THRE errata >> > - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" >> > tree also fixes it. This patch needs to be applied on top of "mm" patch. I think you need to submit your patch to Andrew Morton since it requires a patch from his tree. >> > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( >> > handled = 1; >> > >> > end = NULL; >> > + } else if (up->port.iotype == UPIO_DWAPB && >> > + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { >> Worth aligning this line with the opening paren of if... but's that's >>nitpicking. :-) > No problem I'll change it. I just usually align to the closest tab stop to > the opening parenthesis. It haven't really changed in the last patch. :-) >> > + /* The DesignWare APB UART has an Busy Detect >>(0x07) >> > + * interrupt meaning an LCR write attempt >>occured while the >> > + * UART was busy. The interrupt must be cleared >>by reading >> > + * the UART status register (USR) and the LCR >>re-written. */ >> > + unsigned int status; >> > + status = *(volatile u32 *)up->port.private_data; >> > + serial_out(up, UART_LCR, up->lcr); >> > + >> > + handled = 1; >> > + >> > + end = NULL; >> > } else if (end == NULL) >> > end = l; >> > >> > return 0; >> Still, shouldn't you be doing this in serial8250_timeout() > No, the serial8250_timeout is for issue 1 at the top, this is for > issue 2. It's for lost interrupts, IIUC. They use anothe timeout handler for the workaround... >>also? >>What IRQ numbers this UART is using, BTW? > For the ports on the device they are 27 and 42. Is there any significance > that I'm not aware of? Yeah, IRQ0 is treated as no IRQ by 8250, and in this case it falls back to using serial8250_timeout() to handle "interrupts". >> > diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h >> > index cf23813..bd9711a 100644 >> > --- a/include/linux/serial_core.h >> > +++ b/include/linux/serial_core.h >> > @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( >> > struct device *dev; /* parent >>device */ >> > unsigned char hub6; /* this should >>be in the 8250 driver */ >> > unsigned char unused[3]; >> > + void *private_data; /* >>generic platform data pointer */ >> One tab to many before *private_data... > In my editor using 4 columns per tab it lines up with everything. Is there > some convention that patches should be made assuming 8 columns? Documentation/CodingStyle, chapter 1. :-) >> Oops, your mailer went and did it again. :-) > I'm completely giving up on Thunderbird,unless someone can point out Ypu should have long ago. :-) > the specific internal configuration items which needs a kick! Only the attachments will work in the Mozilla kind mailer, AFAIK. The last patch looked OK at last. :-) > Thanks, > Marc WBR, Sergei From sshtylyov@ru.mvista.com Sat Feb 10 18:21:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sat, 10 Feb 2007 18:21:31 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:48369 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20037584AbXBJSV0 (ORCPT ); Sat, 10 Feb 2007 18:21:26 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 3773C3EC9; Sat, 10 Feb 2007 10:20:50 -0800 (PST) Message-ID: <45CE0CFF.1000105@ru.mvista.com> Date: Sat, 10 Feb 2007 21:20:47 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Thomas Koeller Cc: Russell King , linux-serial@vger.kernel.org, ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] RM9000 serial driver References: <200608102318.52143.thomas.koeller@baslerweb.com> <20060830121216.GA25699@flint.arm.linux.org.uk> <44F5C1BB.7010205@ru.mvista.com> <200702101711.46826.thomas@koeller.dyndns.org> In-Reply-To: <200702101711.46826.thomas@koeller.dyndns.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14029 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Thomas Koeller wrote: >>>>I would like to return to the port type vs. iotype stuff once again. >>>From what you wrote I seem to understand that the iotype is not just >>>>a method of accessing device registers, but also the primary means of >>>>discrimination between different h/w implementations, and hence every >>>>code to support a nonstandard device must define an iotype of its own, >>>>even though one of the existing iotypes would work just fine? >>>iotype is all about the access method used to access the registers of >>>the device, be it by byte or word, and it also takes account of any >>>variance in the addressing of the registers. >>>It does not refer to features or bugs in any particular implementation. >> Well, the introduction of the UPIO_TSI case seems to contradict this -- >>it's exactly about the bugs in the particular UART implementation >>(otherwise well described by UPIO_MEM). Its only function was to mask 2 >>hardware issues. And the UUE bit workaround seems like an abuse to me. The >>driver could just skip the UUE test altogether based on iotype == UPIO_TSI >>(or at least not to ignore writes with UUE set completely like it does but >>just mask off UUE bit). With no provision to pass the implicit UART type >>for platform devices (and skip the autoconfiguation), the introduction of >>UPIO_TSI seems again the necessary evil. Otherwise, we could have this >>handled with a distinct TSI UART type... >>WBR, Sergei > after a long delay (for which I apologize) I would like to return to I should also apologize for my discussion style back then -- I just was short of time (and now I am as well), and might have gotten too nervous for that reason... > this topic. Since so much time has passed since the discussion ceased, I > think I should summarize its state at that point: > 1. In the RM9000 serial driver patch I submitted, I had introduced a new > port type PORT_RM9000. I set the iotype to UPIO_MEM32. Wherever I > needed to handle any peculiarities of the RM9000 h/w, I did so based > upon the port type. AFAICT this is in agreement with Russel's view as > quoted above. It was good in theory but the practice has shown that this approach had a breache. > 2. Sergei says this is wrong, I need to introduce a new iotype instead, > and make the code conditional upon that, like the AU1000 does (UPIO_AU). > The reason he gives (see quote above) is that there is no way to pass > the port type along with a platform device. Is this argument still valid? Of course. > What about including the port type in the information attached to > platform_device.platform_data? As they say, "patches welcome". :-) > Btw., I had a look ath the existing code dealing with platform > devices. Is there a particular reason for not using the standard > platform_device.resource mechanism of passing mem/io/irq resources from > the platform to the driver? Good question... It was probably easier to get all info from one place than to parse the resources. :-) > Another topic discussed was the use (or abuse) of dl_serial_read()/ > dl_serial_write() to get/set the divisor registers. More like necessary evil since Pantelis decided to merge support for the Alchemy UARTs... :-) > 3. Russel says (qoute from an earlier mail), > > It's worse than that - this code is there to read the ID from the divisor > > registers implemented in some UARTs. If it isn't one of those UARTs, > > it's expected to return zero. Could you remind regarding which exactly code Russell has said this, the one in autoconfig_read_divisor_id()? Are you sure this code gets actually called for your UART or Alchemy one? From looking at the code, I could conclude that it shouldn't be -- IIR (sharing address with EFR) shouldn't be reading as zero unless the modem status interrupt is pending -- that's what the EFR detection code counts on... But anyway, I don't see why this code is unsafe to convert to using the dl_serail_read/write accessors... > 4. I followed the AU1X00 code in this case, using the functions to read/write > the divisor value. My hardware has its UART_DLL and UART_DLM registers at > nonstandard addresses, and so the only other option would have been to > monitor every write to the LCR register for setting or clearing the DLAB > bit, and to switch between different mapping tables accordingly. In the Why, if we already have a working approach? > light of this, would it still be unacceptable to use the dl_*() functions > tho access the divisor registers? Why would it be unacceptable, if the like code is already there, in the driver? > Once these issues have been resolved, I will submit an updated version of > my patch. I'm afraid you're on your own with resolving the issues now, as the serial drivers are no longer maintaned by anybody (so, you probably will have to work with Andrew Morton)... > tk MBR, Sergei From ralf@linux-mips.org Sun Feb 11 02:50:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 02:50:35 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:29574 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038405AbXBKCud (ORCPT ); Sun, 11 Feb 2007 02:50:33 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1ALu8Uq012247; Sat, 10 Feb 2007 21:58:48 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1ALu8GW012246; Sat, 10 Feb 2007 21:56:08 GMT Date: Sat, 10 Feb 2007 21:56:08 +0000 From: Ralf Baechle To: Dale Farnsworth Cc: linux-mips@linux-mips.org Subject: Re: Fix eth2 platform device id for jaguar_atx and ocelot_3 platforms Message-ID: <20070210215608.GC9116@linux-mips.org> References: <20070209203142.GA17729@xyzzy.farnsworth.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070209203142.GA17729@xyzzy.farnsworth.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14030 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 09, 2007 at 01:31:43PM -0700, Dale Farnsworth wrote: > Subject: Fix eth2 platform device id for jaguar_atx and ocelot_3 platforms Thanks, applied. Ralf From ralf@linux-mips.org Sun Feb 11 02:50:58 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 02:51:00 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:31110 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038426AbXBKCum (ORCPT ); Sun, 11 Feb 2007 02:50:42 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1AL60vM010327; Sat, 10 Feb 2007 21:08:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1AL5vcK010326; Sat, 10 Feb 2007 21:05:57 GMT Date: Sat, 10 Feb 2007 21:05:57 +0000 From: Ralf Baechle To: Heiko Carstens Cc: Davide Libenzi , linux-mips@linux-mips.org, David Woodhouse , Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper , Andi Kleen Subject: Re: -mm merge plans for 2.6.21 Message-ID: <20070210210557.GA9116@linux-mips.org> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14031 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > Which remembers me that I think that MIPS is using the non-compat version > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > syscall for some reason. Dunno. Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Ralf Signed-off-by: Ralf Baechle diff --git a/arch/x86_64/ia32/ia32entry.S b/arch/x86_64/ia32/ia32entry.S index b4aa875..5993262 100644 --- a/arch/x86_64/ia32/ia32entry.S +++ b/arch/x86_64/ia32/ia32entry.S @@ -718,4 +718,5 @@ ia32_sys_call_table: .quad compat_sys_vmsplice .quad compat_sys_move_pages .quad sys_getcpu + .quad sys_epoll_pwait ia32_syscall_end: From ralf@linux-mips.org Sun Feb 11 02:51:23 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 02:51:26 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:35206 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038444AbXBKCuv (ORCPT ); Sun, 11 Feb 2007 02:50:51 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1ALYlFh010856; Sat, 10 Feb 2007 21:37:27 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1ALYl8e010855; Sat, 10 Feb 2007 21:34:47 GMT Date: Sat, 10 Feb 2007 21:34:47 +0000 From: Ralf Baechle To: David Woodhouse Cc: Heiko Carstens , Davide Libenzi , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 Message-ID: <20070210213447.GB9116@linux-mips.org> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1171103527.29713.228.camel@pmac.infradead.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14032 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sat, Feb 10, 2007 at 10:32:07AM +0000, David Woodhouse wrote: > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > Which remembers me that I think that MIPS is using the non-compat version > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > syscall for some reason. Dunno. > > It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree > there there's 32 bits of padding between the fields of this structure: > > struct epoll_event { > __u32 events; > __u64 data; > }; > > I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 > ABI is different then it would need the compat syscall. That is correct - and apparently for all ABIs because I wasn't able to find a compat_sys_epoll_pwait at all. Unfortunately struct epoll_event contains a gap so it bets on identical padding rules between native and compat ABI and anyway, padding is wasted space so the struct members should have been swapped when this structure was created. Oh well, too late. Ralf From davidel@xmailserver.org Sun Feb 11 04:55:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 04:55:34 +0000 (GMT) Received: from x35.xmailserver.org ([64.71.152.41]:3854 "EHLO x35.xmailserver.org") by ftp.linux-mips.org with ESMTP id S20038446AbXBKEza (ORCPT ); Sun, 11 Feb 2007 04:55:30 +0000 X-AuthUser: davidel@xmailserver.org Received: from alien.or.mcafeemobile.com by x35.xmailserver.org with [XMail 1.25 ESMTP Server] id for from ; Sat, 10 Feb 2007 23:53:57 -0500 Date: Sat, 10 Feb 2007 20:53:52 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Ralf Baechle cc: David Woodhouse , Heiko Carstens , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 In-Reply-To: <20070210213447.GB9116@linux-mips.org> Message-ID: References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> <20070210213447.GB9116@linux-mips.org> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14033 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: davidel@xmailserver.org Precedence: bulk X-list: linux-mips On Sat, 10 Feb 2007, Ralf Baechle wrote: > Unfortunately struct epoll_event contains a gap so it bets on identical > padding rules between native and compat ABI and anyway, padding is wasted > space so the struct members should have been swapped when this structure > was created. Oh well, too late. You really should have needed padding in there, since even if you swapped the members, sizeof(struct epoll_event) would still need to be 16, if alignof(u64) == 8. Either adding an extra auxilliary u32, or make the two members be u64, would have been ok. I'll be posting a patch that adds the compat_ layer for epoll in kernel/compat.c. Architectures that needs it (currently only ARM-EABI and IA64 use a compat code for epoll), should wire them up. - Davide From ak@suse.de Sun Feb 11 10:43:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 10:43:43 +0000 (GMT) Received: from ns.suse.de ([195.135.220.2]:30375 "EHLO mx1.suse.de") by ftp.linux-mips.org with ESMTP id S20038912AbXBKKnh (ORCPT ); Sun, 11 Feb 2007 10:43:37 +0000 Received: from Relay2.suse.de (mail2.suse.de [195.135.221.8]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.suse.de (Postfix) with ESMTP id 59C7412082; Sun, 11 Feb 2007 11:42:17 +0100 (CET) From: Andi Kleen To: Ralf Baechle Subject: Re: -mm merge plans for 2.6.21 Date: Sun, 11 Feb 2007 11:37:45 +0100 User-Agent: KMail/1.9.5 Cc: Heiko Carstens , Davide Libenzi , linux-mips@linux-mips.org, David Woodhouse , Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <20070210210557.GA9116@linux-mips.org> In-Reply-To: <20070210210557.GA9116@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702111137.46344.ak@suse.de> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14034 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ak@suse.de Precedence: bulk X-list: linux-mips On Saturday 10 February 2007 22:05, Ralf Baechle wrote: > On Sat, Feb 10, 2007 at 11:22:05AM +0100, Heiko Carstens wrote: > > > Which remembers me that I think that MIPS is using the non-compat version > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > syscall for some reason. Dunno. > > Which reminds me that x86_64 i386 compat doesn't wire up sys_epoll_pwait ;-) Added thanks. -Andi From SRS0+bf6f6d5a4a10df2b7bef+1267+infradead.org+dwmw2@pentafluge.srs.infradead.org Sun Feb 11 15:37:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 15:37:27 +0000 (GMT) Received: from pentafluge.infradead.org ([213.146.154.40]:11475 "EHLO pentafluge.infradead.org") by ftp.linux-mips.org with ESMTP id S20039028AbXBKPhW (ORCPT ); Sun, 11 Feb 2007 15:37:22 +0000 Received: from [89.192.35.138] (helo=[10.42.195.205]) by pentafluge.infradead.org with esmtpsa (Exim 4.63 #1 (Red Hat Linux)) id 1HGGiG-00077D-9d; Sun, 11 Feb 2007 15:34:03 +0000 Subject: Re: -mm merge plans for 2.6.21 From: David Woodhouse To: Ralf Baechle Cc: Heiko Carstens , Davide Libenzi , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper In-Reply-To: <20070210213447.GB9116@linux-mips.org> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> <20070210213447.GB9116@linux-mips.org> Content-Type: text/plain Date: Sun, 11 Feb 2007 16:33:41 +0100 Message-Id: <1171208022.16494.5.camel@shinybook.infradead.org> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6.dwmw2.1) Content-Transfer-Encoding: 7bit X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14035 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: dwmw2@infradead.org Precedence: bulk X-list: linux-mips On Sat, 2007-02-10 at 21:34 +0000, Ralf Baechle wrote: > Unfortunately struct epoll_event contains a gap so it bets on identical > padding rules between native and compat ABI and anyway, padding is wasted > space so the struct members should have been swapped when this structure > was created. Oh well, too late. Indeed. That was the example I was thinking of when I suggested the "no new syscalls without _simultaneous_ compat version" rule. -- dwmw2 From tglx@linutronix.de Sun Feb 11 15:44:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 15:44:42 +0000 (GMT) Received: from www.osadl.org ([213.239.205.134]:32741 "EHLO mail.tglx.de") by ftp.linux-mips.org with ESMTP id S20039033AbXBKPoh (ORCPT ); Sun, 11 Feb 2007 15:44:37 +0000 Received: from [IPv6:::1] (debian [213.239.205.147]) by mail.tglx.de (Postfix) with ESMTP id 38C4F65C292; Sun, 11 Feb 2007 16:44:06 +0100 (CET) Subject: Re: [PATCH] eXcite nand flash driver From: Thomas Gleixner To: Thomas Koeller Cc: linux-mtd@lists.infradead.org, linux-mips@linux-mips.org In-Reply-To: <200702101122.05049.thomas.koeller@baslerweb.com> References: <200702080157.25432.thomas.koeller@baslerweb.com> <1170949737.3646.29.camel@chaos> <200702101122.05049.thomas.koeller@baslerweb.com> Content-Type: text/plain Date: Sun, 11 Feb 2007 16:44:12 +0100 Message-Id: <1171208652.3661.2.camel@chaos> Mime-Version: 1.0 X-Mailer: Evolution 2.8.2.1 (2.8.2.1-3.fc6) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14036 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: tglx@linutronix.de Precedence: bulk X-list: linux-mips On Sat, 2007-02-10 at 11:22 +0100, Thomas Koeller wrote: > > So I expect an OOPS happens on a regular base. > I guess it is the 'static void __iomem *tgt = NULL' part that worries > you? Think about it, that value is never used. True. > However, I admit it is somewhat unclean, and therefore I am changing > it. Updated patch follows. Yes, it is confusing and looks horrible. tglx From heiko.carstens@de.ibm.com Sun Feb 11 16:17:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 16:17:06 +0000 (GMT) Received: from mtagate4.uk.ibm.com ([195.212.29.137]:48294 "EHLO mtagate4.uk.ibm.com") by ftp.linux-mips.org with ESMTP id S20039047AbXBKQRB (ORCPT ); Sun, 11 Feb 2007 16:17:01 +0000 Received: from d06nrmr1407.portsmouth.uk.ibm.com (d06nrmr1407.portsmouth.uk.ibm.com [9.149.38.185]) by mtagate4.uk.ibm.com (8.13.8/8.13.8) with ESMTP id l1BGFtUl098518; Sun, 11 Feb 2007 16:15:55 GMT Received: from d06av03.portsmouth.uk.ibm.com (d06av03.portsmouth.uk.ibm.com [9.149.37.213]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l1BGFtLJ1884306; Sun, 11 Feb 2007 16:15:55 GMT Received: from d06av03.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l1BGFs8u023924; Sun, 11 Feb 2007 16:15:55 GMT Received: from localhost (ICON-9-164-132-193.megacenter.de.ibm.com [9.164.132.193]) by d06av03.portsmouth.uk.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l1BGFsQu023921; Sun, 11 Feb 2007 16:15:54 GMT Date: Sun, 11 Feb 2007 17:14:46 +0100 From: Heiko Carstens To: Ralf Baechle Cc: David Woodhouse , Davide Libenzi , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 Message-ID: <20070211161446.GB11547@osiris.ibm.com> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> <20070210213447.GB9116@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070210213447.GB9116@linux-mips.org> User-Agent: mutt-ng/devel-r804 (Linux) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14037 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: heiko.carstens@de.ibm.com Precedence: bulk X-list: linux-mips On Sat, Feb 10, 2007 at 09:34:47PM +0000, Ralf Baechle wrote: > On Sat, Feb 10, 2007 at 10:32:07AM +0000, David Woodhouse wrote: > > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > > Which remembers me that I think that MIPS is using the non-compat version > > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > > syscall for some reason. Dunno. > > > > It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree > > there there's 32 bits of padding between the fields of this structure: > > > > struct epoll_event { > > __u32 events; > > __u64 data; > > }; > > > > I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 > > ABI is different then it would need the compat syscall. > > That is correct - and apparently for all ABIs because I wasn't able to find > a compat_sys_epoll_pwait at all. Hmm.. so you don't need to do some fancy compat conversion for the sigset_t that gets passed? Why is that? I don't get it... From davidel@xmailserver.org Sun Feb 11 16:36:24 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 16:36:28 +0000 (GMT) Received: from x35.xmailserver.org ([64.71.152.41]:29966 "EHLO x35.xmailserver.org") by ftp.linux-mips.org with ESMTP id S20039057AbXBKQgY (ORCPT ); Sun, 11 Feb 2007 16:36:24 +0000 X-AuthUser: davidel@xmailserver.org Received: from alien.or.mcafeemobile.com by x35.xmailserver.org with [XMail 1.25 ESMTP Server] id for from ; Sun, 11 Feb 2007 11:34:52 -0500 Date: Sun, 11 Feb 2007 08:34:51 -0800 (PST) From: Davide Libenzi X-X-Sender: davide@alien.or.mcafeemobile.com To: Heiko Carstens cc: Ralf Baechle , David Woodhouse , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 In-Reply-To: <20070211161446.GB11547@osiris.ibm.com> Message-ID: References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> <20070210213447.GB9116@linux-mips.org> <20070211161446.GB11547@osiris.ibm.com> X-GPG-FINGRPRINT: CFAE 5BEE FD36 F65E E640 56FE 0974 BF23 270F 474E X-GPG-PUBLIC_KEY: http://www.xmailserver.org/davidel.asc MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14038 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: davidel@xmailserver.org Precedence: bulk X-list: linux-mips On Sun, 11 Feb 2007, Heiko Carstens wrote: > On Sat, Feb 10, 2007 at 09:34:47PM +0000, Ralf Baechle wrote: > > On Sat, Feb 10, 2007 at 10:32:07AM +0000, David Woodhouse wrote: > > > > > On Sat, 2007-02-10 at 11:22 +0100, Heiko Carstens wrote: > > > > Which remembers me that I think that MIPS is using the non-compat version > > > > of sys_epoll_pwait for compat syscalls. But maybe MIPS doesn't need a compat > > > > syscall for some reason. Dunno. > > > > > > It's OK as long as the 64-bit kernel, N32 and O32 userspace all agree > > > there there's 32 bits of padding between the fields of this structure: > > > > > > struct epoll_event { > > > __u32 events; > > > __u64 data; > > > }; > > > > > > I suspect it's a fairly safe bet that N32 userspace agrees; if the O32 > > > ABI is different then it would need the compat syscall. > > > > That is correct - and apparently for all ABIs because I wasn't able to find > > a compat_sys_epoll_pwait at all. > > Hmm.. so you don't need to do some fancy compat conversion for the sigset_t > that gets passed? Why is that? I don't get it... The compat_sys_epoll_pwait function has two sources of compat. One is the sigset_t and the other one is the struct epoll_event. The sigset_t compat is always needed, while the struct epoll_event may be needed. The code of (upcoming) compat_sys_epoll_pwait takes care of both, with a smart compile-time check to wire sys_epoll_wait or compat_sys_epoll_wait, depending on the need of the struct epoll_event compat handling. So yes, compat_sys_epoll_pwait is needed. - Davide From ralf@linux-mips.org Sun Feb 11 17:12:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 17:12:36 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:19943 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039065AbXBKRMe (ORCPT ); Sun, 11 Feb 2007 17:12:34 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1BG9iSY021141; Sun, 11 Feb 2007 16:12:24 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1BG9gdj021140; Sun, 11 Feb 2007 16:09:42 GMT Date: Sun, 11 Feb 2007 16:09:42 +0000 From: Ralf Baechle To: David Woodhouse Cc: Heiko Carstens , Davide Libenzi , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 Message-ID: <20070211160941.GA20998@linux-mips.org> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> <20070210213447.GB9116@linux-mips.org> <1171208022.16494.5.camel@shinybook.infradead.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1171208022.16494.5.camel@shinybook.infradead.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14039 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 11, 2007 at 04:33:41PM +0100, David Woodhouse wrote: > On Sat, 2007-02-10 at 21:34 +0000, Ralf Baechle wrote: > > Unfortunately struct epoll_event contains a gap so it bets on identical > > padding rules between native and compat ABI and anyway, padding is wasted > > space so the struct members should have been swapped when this structure > > was created. Oh well, too late. > > Indeed. That was the example I was thinking of when I suggested the "no > new syscalls without _simultaneous_ compat version" rule. The need for a compat ABI is not always obvious. Ralf From ralf@linux-mips.org Sun Feb 11 18:03:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Sun, 11 Feb 2007 18:03:29 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:36588 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039062AbXBKSD0 (ORCPT ); Sun, 11 Feb 2007 18:03:26 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1BI1wpw023777; Sun, 11 Feb 2007 18:01:58 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1BI1vjC023776; Sun, 11 Feb 2007 18:01:57 GMT Date: Sun, 11 Feb 2007 18:01:57 +0000 From: Ralf Baechle To: Heiko Carstens Cc: David Woodhouse , Davide Libenzi , linux-mips@linux-mips.org, Andrew Morton , Alexey Dobriyan , Linux Kernel Mailing List , Ulrich Drepper Subject: Re: -mm merge plans for 2.6.21 Message-ID: <20070211180157.GA21492@linux-mips.org> References: <20070208150710.1324f6b4.akpm@linux-foundation.org> <1171042535.29713.96.camel@pmac.infradead.org> <20070209134516.2367a7aa.akpm@linux-foundation.org> <1171058342.29713.136.camel@pmac.infradead.org> <20070210102205.GB8145@osiris.boeblingen.de.ibm.com> <1171103527.29713.228.camel@pmac.infradead.org> <20070210213447.GB9116@linux-mips.org> <20070211161446.GB11547@osiris.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070211161446.GB11547@osiris.ibm.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14040 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Sun, Feb 11, 2007 at 05:14:46PM +0100, Heiko Carstens wrote: > Hmm.. so you don't need to do some fancy compat conversion for the sigset_t > that gets passed? Why is that? I don't get it... Ah, I finally get your point. Yes, that needs conversion. Ralf From thomas@koeller.dyndns.org Mon Feb 12 00:32:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 00:32:07 +0000 (GMT) Received: from mail04.hansenet.de ([213.191.73.12]:53422 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20037573AbXBLAcC (ORCPT ); Mon, 12 Feb 2007 00:32:02 +0000 Received: from [213.39.184.53] (213.39.184.53) by webmail.hansenet.de (7.2.074) (authenticated as mbx20228207@koeller-hh.org) id 45CB2EBD0017FC70; Mon, 12 Feb 2007 01:28:04 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id 0983B479E4; Mon, 12 Feb 2007 01:28:03 +0100 (CET) From: Thomas Koeller To: Sergei Shtylyov Subject: Re: [PATCH] RM9000 serial driver Date: Mon, 12 Feb 2007 01:28:01 +0100 User-Agent: KMail/1.9.6 Cc: Russell King , linux-serial@vger.kernel.org, ralf@linux-mips.org, linux-mips@linux-mips.org References: <200608102318.52143.thomas.koeller@baslerweb.com> <200702101711.46826.thomas@koeller.dyndns.org> <45CE0CFF.1000105@ru.mvista.com> In-Reply-To: <45CE0CFF.1000105@ru.mvista.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702120128.02521.thomas@koeller.dyndns.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14041 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas@koeller.dyndns.org Precedence: bulk X-list: linux-mips On Samstag, 10. Februar 2007, Sergei Shtylyov wrote: > I'm afraid you're on your own with resolving the issues now, as the > serial drivers are no longer maintaned by anybody (so, you probably will > have to work with Andrew Morton)... Thank you for the hint - I did not notice that Russell retired in the meantime. So I'll submit the driver to Andrew directly. regards, tk -- Thomas Koeller thomas@koeller.dyndns.org From thomas.koeller@baslerweb.com Mon Feb 12 01:01:19 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 01:01:24 +0000 (GMT) Received: from mail02.hansenet.de ([213.191.73.62]:26600 "EHLO webmail.hansenet.de") by ftp.linux-mips.org with ESMTP id S20037762AbXBLBBT (ORCPT ); Mon, 12 Feb 2007 01:01:19 +0000 Received: from [213.39.184.53] (213.39.184.53) by webmail.hansenet.de (7.2.074) (authenticated as mbx20228207@koeller-hh.org) id 45CB2B4F0018C249; Mon, 12 Feb 2007 01:57:29 +0100 Received: from localhost.koeller.dyndns.org (localhost.koeller.dyndns.org [127.0.0.1]) by mail.koeller.dyndns.org (Postfix) with ESMTP id B540B479E4; Mon, 12 Feb 2007 01:57:27 +0100 (CET) In-Reply-To: <45CE0CFF.1000105@ru.mvista.com> References: <45CE0CFF.1000105@ru.mvista.com> From: Thomas Koeller Date: Mon, 12 Feb 2007 02:57:27 +0200 Subject: [PATCH] RM9000 serial driver X-Length: 9405 X-UID: 4 To: akpm@osdl.org Cc: Sergei Shtylyov , linux-serial@vger.kernel.org, linux-mips@linux-mips.org MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702120157.27449.thomas.koeller@baslerweb.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14042 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: thomas.koeller@baslerweb.com Precedence: bulk X-list: linux-mips This patch adds support for the integrated serial ports of the MIPS RM9122 processor and its relatives. There has been some discussion about this patch. The interesting part starts here: http://marc.theaimsgroup.com/?l=linux-mips&m=115620115100412&w=2 Signed-off-by: Thomas Koeller --- arch/mips/Kconfig | 3 + drivers/serial/8250.c | 102 +++++++++++++++++++++++++++++++----------- drivers/serial/Kconfig | 9 ++++ include/linux/serial_core.h | 3 +- 4 files changed, 89 insertions(+), 28 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 34a52c8..5317ebb 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -1004,6 +1004,9 @@ config SOC_AU1X00 select SYS_HAS_CPU_MIPS32_R1 select SYS_SUPPORTS_32BIT_KERNEL +config SERIAL_RM9000 + bool + config PNX8550 bool select SOC_PNX8550 diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 5261f0a..3f0fec4 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -251,9 +251,16 @@ static const struct serial8250_config ua .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, .flags = UART_CAP_FIFO | UART_CAP_UUE, }, + [PORT_RM9000] = { + .name = "RM9000", + .fifo_size = 16, + .tx_loadsz = 16, + .fcr = UART_FCR_ENABLE_FIFO | UART_FCR_R_TRIG_10, + .flags = UART_CAP_FIFO, + }, }; -#ifdef CONFIG_SERIAL_8250_AU1X00 +#if defined (CONFIG_SERIAL_8250_AU1X00) /* Au1x00 UART hardware has a weird register layout */ static const u8 au_io_in_map[] = { @@ -289,6 +296,36 @@ static inline int map_8250_out_reg(struc return au_io_out_map[offset]; } +#elif defined (CONFIG_SERIAL_8250_RM9K) + +static const u8 + regmap_in[8] = { + [UART_RX] = 0x00, + [UART_IER] = 0x0c, + [UART_IIR] = 0x14, + [UART_LCR] = 0x1c, + [UART_MCR] = 0x20, + [UART_LSR] = 0x24, + [UART_MSR] = 0x28, + [UART_SCR] = 0x2c + }, + regmap_out[8] = { + [UART_TX] = 0x04, + [UART_IER] = 0x0c, + [UART_FCR] = 0x18, + [UART_LCR] = 0x1c, + [UART_MCR] = 0x20, + [UART_LSR] = 0x24, + [UART_MSR] = 0x28, + [UART_SCR] = 0x2c + }; + +#define map_8250_in_reg(up, offset) \ + (((up)->port.type == PORT_RM9000) ? regmap_in[offset] : (offset)) +#define map_8250_out_reg(up, offset) \ + (((up)->port.type == PORT_RM9000) ? regmap_out[offset] : (offset)) + + #else /* sane hardware needs no mapping */ @@ -374,21 +411,21 @@ #define serial_inp(up, offset) serial_i #define serial_outp(up, offset, value) serial_out(up, offset, value) /* Uart divisor latch read */ -static inline int _serial_dl_read(struct uart_8250_port *up) +static inline unsigned int _serial_dl_read(struct uart_8250_port *up) { return serial_inp(up, UART_DLL) | serial_inp(up, UART_DLM) << 8; } /* Uart divisor latch write */ -static inline void _serial_dl_write(struct uart_8250_port *up, int value) +static inline void _serial_dl_write(struct uart_8250_port *up, unsigned int value) { serial_outp(up, UART_DLL, value & 0xff); serial_outp(up, UART_DLM, value >> 8 & 0xff); } -#ifdef CONFIG_SERIAL_8250_AU1X00 +#if defined (CONFIG_SERIAL_8250_AU1X00) /* Au1x00 haven't got a standard divisor latch */ -static int serial_dl_read(struct uart_8250_port *up) +static unsigned int serial_dl_read(struct uart_8250_port *up) { if (up->port.iotype == UPIO_AU) return __raw_readl(up->port.membase + 0x28); @@ -396,13 +433,26 @@ static int serial_dl_read(struct uart_82 return _serial_dl_read(up); } -static void serial_dl_write(struct uart_8250_port *up, int value) +static void serial_dl_write(struct uart_8250_port *up, unsigned int value) { if (up->port.iotype == UPIO_AU) __raw_writel(value, up->port.membase + 0x28); else _serial_dl_write(up, value); } +#elif defined (CONFIG_SERIAL_8250_RM9K) +static inline unsigned int serial_dl_read(struct uart_8250_port *up) +{ + return + ((readl(up->port.membase + 0x10) << 8) | + (readl(up->port.membase + 0x08) & 0xff)) & 0xffff; +} + +static inline void serial_dl_write(struct uart_8250_port *up, unsigned int value) +{ + writel(value, up->port.membase + 0x08); + writel(value >> 8, up->port.membase + 0x10); +} #else #define serial_dl_read(up) _serial_dl_read(up) #define serial_dl_write(up, value) _serial_dl_write(up, value) @@ -576,22 +626,17 @@ static int size_fifo(struct uart_8250_po */ static unsigned int autoconfig_read_divisor_id(struct uart_8250_port *p) { - unsigned char old_dll, old_dlm, old_lcr; - unsigned int id; + unsigned char old_lcr; + unsigned int id, old_dl; old_lcr = serial_inp(p, UART_LCR); serial_outp(p, UART_LCR, UART_LCR_DLAB); + old_dl = _serial_dl_read(p); - old_dll = serial_inp(p, UART_DLL); - old_dlm = serial_inp(p, UART_DLM); + serial_dl_write(p, 0); + id = serial_dl_read(p); - serial_outp(p, UART_DLL, 0); - serial_outp(p, UART_DLM, 0); - - id = serial_inp(p, UART_DLL) | serial_inp(p, UART_DLM) << 8; - - serial_outp(p, UART_DLL, old_dll); - serial_outp(p, UART_DLM, old_dlm); + serial_dl_write(p, old_dl); serial_outp(p, UART_LCR, old_lcr); return id; @@ -604,7 +649,7 @@ static unsigned int autoconfig_read_divi * its clones. (We treat the broken original StarTech 16650 V1 as a * 16550, and why not? Startech doesn't seem to even acknowledge its * existence.) - * + * * What evil have men's minds wrought... */ static void autoconfig_has_efr(struct uart_8250_port *up) @@ -657,7 +702,7 @@ static void autoconfig_has_efr(struct ua up->bugs |= UART_BUG_QUOT; return; } - + /* * We check for a XR16C850 by setting DLL and DLM to 0, and then * reading back DLL and DLM. The chip type depends on the DLM @@ -800,7 +845,7 @@ static void autoconfig_16550a(struct uar status1 &= ~0xB0; /* Disable LOCK, mask out PRESL[01] */ status1 |= 0x10; /* 1.625 divisor for baud_base --> 921600 */ serial_outp(up, 0x04, status1); - + serial_dl_write(up, quot); serial_outp(up, UART_LCR, 0); @@ -905,7 +950,7 @@ static void autoconfig(struct uart_8250_ /* * Do a simple existence test first; if we fail this, * there's no point trying anything else. - * + * * 0x80 is used as a nonsense port to prevent against * false positives due to ISA bus float. The * assumption is that 0x80 is a non-existent port; @@ -940,7 +985,7 @@ #endif save_mcr = serial_in(up, UART_MCR); save_lcr = serial_in(up, UART_LCR); - /* + /* * Check to see if a UART is really there. Certain broken * internal modems based on the Rockwell chipset fail this * test, because they apparently don't implement the loopback @@ -1047,7 +1092,7 @@ #endif else serial_outp(up, UART_IER, 0); - out: + out: spin_unlock_irqrestore(&up->port.lock, flags); // restore_flags(flags); DEBUG_AUTOCONF("type=%s\n", uart_config[up->port.type].name); @@ -1073,7 +1118,7 @@ static void autoconfig_irq(struct uart_8 save_mcr = serial_inp(up, UART_MCR); save_ier = serial_inp(up, UART_IER); serial_outp(up, UART_MCR, UART_MCR_OUT1 | UART_MCR_OUT2); - + irqs = probe_irq_on(); serial_outp(up, UART_MCR, 0); udelay (10); @@ -1138,8 +1183,11 @@ static void serial8250_start_tx(struct u if (up->bugs & UART_BUG_TXEN) { unsigned char lsr, iir; lsr = serial_in(up, UART_LSR); - iir = serial_in(up, UART_IIR); - if (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT) + iir = serial_in(up, UART_IIR) & 0x0f; + if ((up->port.type == PORT_RM9000) ? + (lsr & UART_LSR_THRE && + (iir == UART_IIR_NO_INT || iir == UART_IIR_THRI)) : + (lsr & UART_LSR_TEMT && iir & UART_IIR_NO_INT)) transmit_chars(up); } } @@ -1801,7 +1849,7 @@ #endif /* * Ask the core to calculate the divisor for us. */ - baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16); + baud = uart_get_baud_rate(port, termios, old, 0, port->uartclk/16); quot = serial8250_get_divisor(port, baud); /* diff --git a/drivers/serial/Kconfig b/drivers/serial/Kconfig index 9ddfb84..228ae12 100644 --- a/drivers/serial/Kconfig +++ b/drivers/serial/Kconfig @@ -254,6 +254,15 @@ config SERIAL_8250_AU1X00 to this option. The driver can handle 1 or 2 serial ports. If unsure, say N. +config SERIAL_8250_RM9K + bool "Support for MIPS RM9xxx integrated serial port" + depends on SERIAL_8250 != n && SERIAL_RM9000 + select SERIAL_8250_SHARE_IRQ + help + Selecting this option will add support for the integrated serial + port hardware found on MIPS RM9122 and similar processors. + If unsure, say N. + comment "Non-8250 serial port support" config SERIAL_AMBA_PL010 diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index cf23813..275392f 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -39,7 +39,8 @@ #define PORT_16850 12 #define PORT_RSA 13 #define PORT_NS16550A 14 #define PORT_XSCALE 15 -#define PORT_MAX_8250 15 /* max port ID */ +#define PORT_RM9000 16 /* PMC-Sierra RM9xxx internal UART */ +#define PORT_MAX_8250 16 /* max port ID */ /* * ARM specific type numbers. These are not currently guaranteed -- 1.4.3 From vagabon.xyz@gmail.com Mon Feb 12 08:45:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 08:45:40 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.225]:15632 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038442AbXBLIpf (ORCPT ); Mon, 12 Feb 2007 08:45:35 +0000 Received: by qb-out-0506.google.com with SMTP id e12so536855qba for ; Mon, 12 Feb 2007 00:44:34 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NuVuowrc3P+Ukzo8i85eqAV2WTVoCRxZgIrNZ04KtF51UYCtAJNOp7Lr0ZLFRSDzF9XtPkG4YDmPXBDeDeP13kVH2M1stzm3QvbXFn5yFcZhUcfXSmO+9c5CU0TS1D45nG2DYTRQbNUEi9ZTf4BGzIf+qcO+QPKu+dihkVpAHMA= Received: by 10.114.254.1 with SMTP id b1mr5556353wai.1171269873302; Mon, 12 Feb 2007 00:44:33 -0800 (PST) Received: by 10.114.136.11 with HTTP; Mon, 12 Feb 2007 00:44:33 -0800 (PST) Message-ID: Date: Mon, 12 Feb 2007 09:44:33 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] clean up ret_from_{irq,exception} Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070211.004020.79071872.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45C8A477.8070906@innova-card.com> <20070211.004020.79071872.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14043 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi Atsushi, On 2/10/07, Atsushi Nemoto wrote: > Maybe this would be better? > > #ifdef CONFIG_PREEMPT > FEXPORT(ret_from_irq) > LONG_S s0, TI_REGS($28) > FEXPORT(ret_from_exception) > #else > FEXPORT(ret_from_exception) > local_irq_disable # preempt stop > b _ret_from_irq > FEXPORT(ret_from_irq) > LONG_S s0, TI_REGS($28) > #endif > FEXPORT(_ret_from_irq) > well maybe this one would be more readable: -- >8 -- diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S index f10b6a1..b5d27d5 100644 --- a/arch/mips/kernel/entry.S +++ b/arch/mips/kernel/entry.S @@ -21,23 +21,20 @@ #endif #ifndef CONFIG_PREEMPT - .macro preempt_stop - local_irq_disable - .endm #define resume_kernel restore_all +#else +#define _ret_from_irq ret_from_exception #endif .text .align 5 -FEXPORT(ret_from_irq) - LONG_S s0, TI_REGS($28) -#ifdef CONFIG_PREEMPT +#ifndef CONFIG_PREEMPT FEXPORT(ret_from_exception) -#else + local_irq_disable # preempt stop b _ret_from_irq -FEXPORT(ret_from_exception) - preempt_stop #endif +FEXPORT(ret_from_irq) + LONG_S s0, TI_REGS($28) FEXPORT(_ret_from_irq) LONG_L t0, PT_STATUS(sp) # returning to kernel mode? andi t0, t0, KU_USER -- Franck From vagabon.xyz@gmail.com Mon Feb 12 09:02:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 09:02:25 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.237]:34083 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038520AbXBLJCU (ORCPT ); Mon, 12 Feb 2007 09:02:20 +0000 Received: by qb-out-0506.google.com with SMTP id e12so539722qba for ; Mon, 12 Feb 2007 01:01:19 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=n0uO21anpFrOKlUhkC6c8Gzt7VLuUO/69ykK1doSkpfcpnls7zcZGHs52cDFkpecYZpz86L2mVHr11gbYU5mNaQk0p90Iu+0a3Nrh0Txg97eYa3dO2DrJ9iuiGBbPlPEc6l+Cdve5rCHgN31sMCz6XZEjIazaad62pEIsmbROCk= Received: by 10.114.197.1 with SMTP id u1mr5568082waf.1171270878410; Mon, 12 Feb 2007 01:01:18 -0800 (PST) Received: by 10.114.136.11 with HTTP; Mon, 12 Feb 2007 01:01:18 -0800 (PST) Message-ID: Date: Mon, 12 Feb 2007 10:01:18 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Cc: "Franck Bui-Huu" , "Atsushi Nemoto" , linux-mips@linux-mips.org In-Reply-To: <20070209210014.GA26939@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336591652-git-send-email-fbuihuu@gmail.com> <20070210.011835.08318488.anemo@mba.ocn.ne.jp> <61ec3ea90702090834k774bf18bwf7ec5f7b10349779@mail.gmail.com> <20070209210014.GA26939@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14044 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/9/07, Ralf Baechle wrote: > Which is quite a funny C problem to solve :-) > How about this instead ? -- >8 -- diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index 1cdd4ee..ab7fe1c 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -265,7 +265,7 @@ do { \ */ #define __get_user_asm_ll32(val, addr) \ { \ - unsigned long long __gu_tmp; \ + __typeof__(*(addr)) __gu_tmp; \ \ __asm__ __volatile__( \ "1: lw %1, (%3) \n" \ @@ -283,7 +283,7 @@ do { \ " .previous \n" \ : "=r" (__gu_err), "=&r" (__gu_tmp) \ : "0" (0), "r" (addr), "i" (-EFAULT)); \ - (val) = (__typeof__(*(addr))) __gu_tmp; \ + (val) = __gu_tmp; \ } /* -- Franck From anemo@mba.ocn.ne.jp Mon Feb 12 14:46:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 14:47:01 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:19438 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038825AbXBLOq7 (ORCPT ); Mon, 12 Feb 2007 14:46:59 +0000 Received: from localhost (p7240-ipad209funabasi.chiba.ocn.ne.jp [58.88.118.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 61282A9B5; Mon, 12 Feb 2007 23:45:38 +0900 (JST) Date: Mon, 12 Feb 2007 23:45:38 +0900 (JST) Message-Id: <20070212.234538.25910340.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] clean up ret_from_{irq,exception} From: Atsushi Nemoto In-Reply-To: References: <45C8A477.8070906@innova-card.com> <20070211.004020.79071872.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14045 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 12 Feb 2007 09:44:33 +0100, "Franck Bui-Huu" wrote: > well maybe this one would be more readable: > > -- >8 -- > > diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S > index f10b6a1..b5d27d5 100644 > --- a/arch/mips/kernel/entry.S > +++ b/arch/mips/kernel/entry.S > @@ -21,23 +21,20 @@ > #endif > > #ifndef CONFIG_PREEMPT > - .macro preempt_stop > - local_irq_disable > - .endm > #define resume_kernel restore_all > +#else > +#define _ret_from_irq ret_from_exception > #endif _ret_from_irq is used by dec/int-handler.S directly, so you should not remove it (though decstation_defconfig disables CONFIG_PREEMPT). But looking at dec/int-handler.S again, I can not see why it uses _ret_from_irq, and why it manipulates TI_REGS($28) in handle_it ... It seems dec/int-handler.S has been broken for a while. I'll send a patch to fix it. If it was ACKed, I ACK your patch. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Mon Feb 12 14:49:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 14:49:48 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:43999 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038835AbXBLOtq (ORCPT ); Mon, 12 Feb 2007 14:49:46 +0000 Received: from localhost (p7240-ipad209funabasi.chiba.ocn.ne.jp [58.88.118.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id BD5D2B6B9; Mon, 12 Feb 2007 23:48:26 +0900 (JST) Date: Mon, 12 Feb 2007 23:48:26 +0900 (JST) Message-Id: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Cc: ralf@linux-mips.org, vagabon.xyz@gmail.com Subject: [PATCH] fix irq handling of DECstations From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14046 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips It looks 2.6.19 or 2.6.20 does not work on DECStations. When I post a patch (commit f431baa55abf8adeed0c718b51deacbc151f58f1), I just tried to not change behavior of existing codes, but it seems dec/int-handler.S had been broken since its previous commit 937a801576f954bd030d7c4a5a94571710d87c0b. The caller of plat_irq_dispatch do setup/restore TI_REGS($28), so dec's plat_irq_dispatch should not do it, and there is no need to adjust RA. Signed-off-by: Atsushi Nemoto --- diff --git a/arch/mips/dec/int-handler.S b/arch/mips/dec/int-handler.S index b251ef8..00cecdc 100644 --- a/arch/mips/dec/int-handler.S +++ b/arch/mips/dec/int-handler.S @@ -264,9 +264,6 @@ srlv t3,t1,t2 handle_it: - LONG_L s0, TI_REGS($28) - LONG_S sp, TI_REGS($28) - PTR_LA ra, ret_from_irq j dec_irq_dispatch nop @@ -277,7 +274,6 @@ fpu: #endif spurious: - PTR_LA ra, _ret_from_irq j spurious_interrupt nop END(plat_irq_dispatch) From ralf@linux-mips.org Mon Feb 12 15:05:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 15:05:49 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:62668 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038853AbXBLPFr (ORCPT ); Mon, 12 Feb 2007 15:05:47 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1CE50E9009772; Mon, 12 Feb 2007 14:07:40 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1CE4xUl009769; Mon, 12 Feb 2007 14:04:59 GMT Date: Mon, 12 Feb 2007 14:04:59 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Franck Bui-Huu , Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Message-ID: <20070212140459.GA9679@linux-mips.org> References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336591652-git-send-email-fbuihuu@gmail.com> <20070210.011835.08318488.anemo@mba.ocn.ne.jp> <61ec3ea90702090834k774bf18bwf7ec5f7b10349779@mail.gmail.com> <20070209210014.GA26939@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14047 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 12, 2007 at 10:01:18AM +0100, Franck Bui-Huu wrote: > How about this instead ? Won't work for a pointer to some const thing. Ralf From anemo@mba.ocn.ne.jp Mon Feb 12 15:27:06 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 15:27:07 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:47057 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038834AbXBLP1G (ORCPT ); Mon, 12 Feb 2007 15:27:06 +0000 Received: from localhost (p7240-ipad209funabasi.chiba.ocn.ne.jp [58.88.118.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 1C1B5A53B; Tue, 13 Feb 2007 00:25:46 +0900 (JST) Date: Tue, 13 Feb 2007 00:25:45 +0900 (JST) Message-Id: <20070213.002545.03977174.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: vagabon.xyz@gmail.com, fbuihuu@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel From: Atsushi Nemoto In-Reply-To: <20070212140459.GA9679@linux-mips.org> References: <20070209210014.GA26939@linux-mips.org> <20070212140459.GA9679@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14048 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 12 Feb 2007 14:04:59 +0000, Ralf Baechle wrote: > > How about this instead ? > > Won't work for a pointer to some const thing. And recent commit 4ed3a77f38c023658784804cb39a7ce18063dc88 reverts commit 3218357c94af92478ef39163163a81e654385320. Round and round and round and ... --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Mon Feb 12 15:52:33 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 15:52:41 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:65521 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038870AbXBLPwd (ORCPT ); Mon, 12 Feb 2007 15:52:33 +0000 Received: from localhost (p7240-ipad209funabasi.chiba.ocn.ne.jp [58.88.118.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 27EC6B420 for ; Tue, 13 Feb 2007 00:51:14 +0900 (JST) Date: Tue, 13 Feb 2007 00:51:13 +0900 (JST) Message-Id: <20070213.005113.89067116.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: struct sigcontext for N32 userland From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14049 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips If N32 userland refers asm-mips/sigcontext.h, struct sigcontext cause some troubles. #if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 struct sigcontext { unsigned long sc_regs[32]; ... The kernel use 64-bit for sc_regs[0], and both N32/N64 userland expects it was 64-bit. But size of 'long' on N32 is actually 32-bit. So this definition make some confusion. glibc has its own sigcontext.h and it uses 'unsigned long long' for sc_regs, so no real problem with glibc. Should we use 'unsigned long long' here as glibc does? Or should we have separate definition just for N32 userland? (kernel does not use #if _MIPS_SIM == _MIPS_SIM_NABI32 block anyway since kernel itself is compiled as n64) Or should we make struct sigcontext private to kernel and do not export for userland at all? Or ... do nothing? --- Atsushi Nemoto From vagabon.xyz@gmail.com Mon Feb 12 15:56:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 15:57:00 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.239]:41257 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038870AbXBLP44 (ORCPT ); Mon, 12 Feb 2007 15:56:56 +0000 Received: by qb-out-0506.google.com with SMTP id e12so607185qba for ; Mon, 12 Feb 2007 07:55:51 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZSKdRfsSIzSQzMjG5C3j6e7L1ELII5rTmFtxIkwDNh4NEongGRlLsJZlaK+C66aD9VP5PMO9nhgKGT7nbBKsMgzwxhA9fUFwcv2KGdAdZ5tw281dtWbYY0IMaB4uD9D2YcuZbebewS/4EBBwdRRZN7Np+ICzWmISEJmY6/NCM8s= Received: by 10.115.108.1 with SMTP id k1mr5935110wam.1171295750280; Mon, 12 Feb 2007 07:55:50 -0800 (PST) Received: by 10.114.136.11 with HTTP; Mon, 12 Feb 2007 07:55:50 -0800 (PST) Message-ID: Date: Mon, 12 Feb 2007 16:55:50 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH] clean up ret_from_{irq,exception} Cc: ralf@linux-mips.org, linux-mips@linux-mips.org In-Reply-To: <20070212.234538.25910340.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45C8A477.8070906@innova-card.com> <20070211.004020.79071872.anemo@mba.ocn.ne.jp> <20070212.234538.25910340.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14050 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/12/07, Atsushi Nemoto wrote: > > _ret_from_irq is used by dec/int-handler.S directly, so you should not > remove it (though decstation_defconfig disables CONFIG_PREEMPT). > woah, you're right. the name '_ret_from_irq' looks so private to me that I didn't think that some other code could use it... > But looking at dec/int-handler.S again, I can not see why it uses > _ret_from_irq, and why it manipulates TI_REGS($28) in handle_it ... > > It seems dec/int-handler.S has been broken for a while. I'll send a > patch to fix it. If it was ACKed, I ACK your patch. > ok I'm waiting... -- Franck From macro@linux-mips.org Mon Feb 12 16:52:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 16:52:39 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:26380 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20038946AbXBLQwe (ORCPT ); Mon, 12 Feb 2007 16:52:34 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 7AB6DE1CD1; Mon, 12 Feb 2007 17:51:49 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Ijkn9JVpVMFd; Mon, 12 Feb 2007 17:51:49 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 09B8FE1CA0; Mon, 12 Feb 2007 17:51:49 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l1CGq2BY012779; Mon, 12 Feb 2007 17:52:02 +0100 Date: Mon, 12 Feb 2007 16:51:57 +0000 (GMT) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] clean up ret_from_{irq,exception} In-Reply-To: <20070212.234538.25910340.anemo@mba.ocn.ne.jp> Message-ID: References: <45C8A477.8070906@innova-card.com> <20070211.004020.79071872.anemo@mba.ocn.ne.jp> <20070212.234538.25910340.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2558/Mon Feb 12 13:54:21 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14051 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, 12 Feb 2007, Atsushi Nemoto wrote: > _ret_from_irq is used by dec/int-handler.S directly, so you should not > remove it (though decstation_defconfig disables CONFIG_PREEMPT). > > But looking at dec/int-handler.S again, I can not see why it uses > _ret_from_irq, and why it manipulates TI_REGS($28) in handle_it ... > > It seems dec/int-handler.S has been broken for a while. I'll send a > patch to fix it. If it was ACKed, I ACK your patch. It works for me with 2.6.18 -- if it needs an update due to more recent changes, then I have not got there yet. ;-) I plan to rewrite this bit in C if feasible like other platforms did too. Maciej From anemo@mba.ocn.ne.jp Mon Feb 12 17:02:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 17:03:01 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:28113 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038879AbXBLRCz (ORCPT ); Mon, 12 Feb 2007 17:02:55 +0000 Received: from localhost (p7240-ipad209funabasi.chiba.ocn.ne.jp [58.88.118.240]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id A9873AD6E; Tue, 13 Feb 2007 02:01:34 +0900 (JST) Date: Tue, 13 Feb 2007 02:01:34 +0900 (JST) Message-Id: <20070213.020134.18306317.anemo@mba.ocn.ne.jp> To: macro@linux-mips.org Cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] clean up ret_from_{irq,exception} From: Atsushi Nemoto In-Reply-To: References: <20070212.234538.25910340.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14052 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 12 Feb 2007 16:51:57 +0000 (GMT), "Maciej W. Rozycki" wrote: > > It seems dec/int-handler.S has been broken for a while. I'll send a > > patch to fix it. If it was ACKed, I ACK your patch. > > It works for me with 2.6.18 -- if it needs an update due to more recent > changes, then I have not got there yet. ;-) I plan to rewrite this bit in > C if feasible like other platforms did too. The breakage happened during 2.6.19 development cycle (large pt_regs argument removal). --- Atsushi Nemoto From Marc_St-Jean@pmc-sierra.com Mon Feb 12 17:47:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 17:47:32 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:33969 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039003AbXBLRr0 (ORCPT ); Mon, 12 Feb 2007 17:47:26 +0000 Received: (qmail 9835 invoked by uid 101); 12 Feb 2007 17:46:18 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by mother.pmc-sierra.com with SMTP; 12 Feb 2007 17:46:18 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1CHkCic022124; Mon, 12 Feb 2007 09:46:17 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7WMZV>; Mon, 12 Feb 2007 09:46:12 -0800 Message-ID: <45D0A7DA.1040305@pmc-sierra.com> From: Marc St-Jean To: Sergei Shtylyov Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Mon, 12 Feb 2007 09:46:02 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 12 Feb 2007 17:46:07.0677 (UTC) FILETIME=[ACBE66D0:01C74ECD] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14053 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Sergei Shtylyov wrote: > Hello. > > Marc St-Jean wrote: > > >> > Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx > >>device. > > I think you need to submit your patch to Andrew Morton since it > requires a patch from his tree. OK, will do. > >> > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( > >> > handled = 1; > >> > > >> > end = NULL; > >> > + } else if (up->port.iotype == UPIO_DWAPB && > >> > + (iir & UART_IIR_BUSY) == > UART_IIR_BUSY) { > > >> Worth aligning this line with the opening paren of if... but's > that's > >>nitpicking. :-) > > > No problem I'll change it. I just usually align to the closest tab > stop to > > the opening parenthesis. > > It haven't really changed in the last patch. :-) I will respin with 8 char tabs. > >> > + /* The DesignWare APB UART has an Busy Detect > >>(0x07) > >> > + * interrupt meaning an LCR write attempt > >>occured while the > >> > + * UART was busy. The interrupt must be cleared > >>by reading > >> > + * the UART status register (USR) and the LCR > >>re-written. */ > >> > + unsigned int status; > >> > + status = *(volatile u32 > *)up->port.private_data; > >> > + serial_out(up, UART_LCR, up->lcr); > >> > + > >> > + handled = 1; > >> > + > >> > + end = NULL; > >> > } else if (end == NULL) > >> > end = l; > >> > > >> > return 0; > > >> Still, shouldn't you be doing this in serial8250_timeout() > > > No, the serial8250_timeout is for issue 1 at the top, this is for > > issue 2. > > It's for lost interrupts, IIUC. They use anothe timeout handler for the > workaround... This issue (2) is a completely new type of interrupt generated but the DesignWare APB uart, it has nothing to do with lost interrupts. > >>also? > >>What IRQ numbers this UART is using, BTW? > > > For the ports on the device they are 27 and 42. Is there any > significance > > that I'm not aware of? > > Yeah, IRQ0 is treated as no IRQ by 8250, and in this case it falls > back to > using serial8250_timeout() to handle "interrupts". Good to know. It won't be affecting us then. > > >> Oops, your mailer went and did it again. :-) > > > I'm completely giving up on Thunderbird,unless someone can point out > > Ypu should have long ago. :-) > > > the specific internal configuration items which needs a kick! > > Only the attachments will work in the Mozilla kind mailer, AFAIK. > The last patch looked OK at last. :-) The attachemnents appear to be MIME which is a no-no according the linux FAQ at kernel.org. I guess I'll stick with /bin/mail. Thanks, Marc From sshtylyov@ru.mvista.com Mon Feb 12 17:57:04 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 17:57:08 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:27171 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039009AbXBLR5E (ORCPT ); Mon, 12 Feb 2007 17:57:04 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 75B1D3EC9; Mon, 12 Feb 2007 09:56:29 -0800 (PST) Message-ID: <45D0AA49.8060006@ru.mvista.com> Date: Mon, 12 Feb 2007 20:56:25 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Marc St-Jean Cc: linux-serial@vger.kernel.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er References: <45D0A7DA.1040305@pmc-sierra.com> In-Reply-To: <45D0A7DA.1040305@pmc-sierra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14054 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Marc St-Jean wrote: >> >> > Fourth attempt at the serial driver patch for the PMC-Sierra MSP71xx >> >>device. >> I think you need to submit your patch to Andrew Morton since it >>requires a patch from his tree. > OK, will do. In fact, since the serial drivers are not maintained anymore, this seems the only option. >> >> > + /* The DesignWare APB UART has an Busy Detect >> >>(0x07) >> >> > + * interrupt meaning an LCR write attempt >> >>occured while the >> >> > + * UART was busy. The interrupt must be cleared >> >>by reading >> >> > + * the UART status register (USR) and the LCR >> >>re-written. */ >> >> > + unsigned int status; >> >> > + status = *(volatile u32 >>*)up->port.private_data; >> >> > + serial_out(up, UART_LCR, up->lcr); >> >> > + >> >> > + handled = 1; >> >> > + >> >> > + end = NULL; >> >> > } else if (end == NULL) >> >> > end = l; >> >> > return 0; >> >> Still, shouldn't you be doing this in serial8250_timeout() >> > No, the serial8250_timeout is for issue 1 at the top, this is for >> > issue 2. >> It's for lost interrupts, IIUC. They use anothe timeout handler for the >>workaround... > This issue (2) is a completely new type of interrupt generated but the > DesignWare APB uart, it has nothing to do with lost interrupts. Yeah, I just thought that the lost interrupts might be a "generic" issue. >> >>also? >> >>What IRQ numbers this UART is using, BTW? >> > For the ports on the device they are 27 and 42. Is there any >>significance >> > that I'm not aware of? >> Yeah, IRQ0 is treated as no IRQ by 8250, and in this case it falls >>back to using serial8250_timeout() to handle "interrupts". > Good to know. It won't be affecting us then. This may be overriden anyway... >> >> Oops, your mailer went and did it again. :-) >> > I'm completely giving up on Thunderbird,unless someone can point out >> Ypu should have long ago. :-) >> > the specific internal configuration items which needs a kick! >> Only the attachments will work in the Mozilla kind mailer, AFAIK. >>The last patch looked OK at last. :-) > The attachemnents appear to be MIME which is a no-no according the The text/plain type attachments seem to be acceptable for the most maintainers. This Mozilla can do, at least. :-) > linux FAQ at kernel.org. I guess I'll stick with /bin/mail. > Thanks, > Marc WBR, Sergei From djohnson@sw.starentnetworks.com Mon Feb 12 22:50:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Mon, 12 Feb 2007 22:50:48 +0000 (GMT) Received: from newmail.sw.starentnetworks.com ([12.33.234.78]:28828 "EHLO mail.sw.starentnetworks.com") by ftp.linux-mips.org with ESMTP id S20039135AbXBLWun (ORCPT ); Mon, 12 Feb 2007 22:50:43 +0000 Received: from zeus.sw.starentnetworks.com (zeus.sw.starentnetworks.com [12.33.233.46]) by mail.sw.starentnetworks.com (Postfix) with ESMTP id 4C71A3EC0C; Mon, 12 Feb 2007 17:49:56 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17872.61204.190437.109367@zeus.sw.starentnetworks.com> Date: Mon, 12 Feb 2007 17:49:56 -0500 From: Dave Johnson To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: problems booting sb1250, page fault issue? In-Reply-To: <20070211.010336.15248113.anemo@mba.ocn.ne.jp> References: <17869.2075.900049.547334@zeus.sw.starentnetworks.com> <20070211.010336.15248113.anemo@mba.ocn.ne.jp> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14055 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djohnson+linux-mips@sw.starentnetworks.com Precedence: bulk X-list: linux-mips Atsushi Nemoto writes: > You mean 2.6.18 is OK and more recent kernel has problem? Or 2.6.18 > has problem? 2.6.18 has the problem. I haven't tried a more recent version. > Is this problem still happen in 2.6.20? > > Please refer this thread: > > http://www.linux-mips.org/cgi-bin/mesg.cgi?a=linux-mips&i=710F16C36810444CA2F5821E5EAB7F230A0DFA%40NT-SJCA-0752.brcm.ad.broadcom.com I added both flush_data_cache_page to c-sb1.c and __flush_icache_page() to flush_icache_page in cacheflush.h. With those, the page faults work correctly and booting seems to be reliable on 2.6.18. Thanks. -- Dave Johnson Starent Networks From memorylost@tin.it Tue Feb 13 06:04:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 06:04:28 +0000 (GMT) Received: from smtp-out02.alice.it ([85.33.2.6]:28676 "EHLO smtp-out02.alice.it") by ftp.linux-mips.org with ESMTP id S20037808AbXBMGEW (ORCPT ); Tue, 13 Feb 2007 06:04:22 +0000 Received: from FBCMMO03.fbc.local ([192.168.68.197]) by smtp-out02.alice.it with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 07:03:54 +0100 Received: from FBCMCL01B06.fbc.local ([192.168.69.87]) by FBCMMO03.fbc.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 07:03:54 +0100 Received: from [192.168.1.200] ([82.49.75.20]) by FBCMCL01B06.fbc.local with Microsoft SMTPSVC(6.0.3790.1830); Tue, 13 Feb 2007 07:03:54 +0100 Message-ID: <45D154C2.9030809@tin.it> Date: Tue, 13 Feb 2007 07:03:46 +0100 From: Lucio Dona' User-Agent: Mozilla Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: AU1100 Ethernet problems Content-Type: multipart/signed; protocol="application/x-pkcs7-signature"; micalg=sha1; boundary="------------ms020508000201000800020508" X-OriginalArrivalTime: 13 Feb 2007 06:03:54.0623 (UTC) FILETIME=[BDE650F0:01C74F34] Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14056 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: memorylost@tin.it Precedence: bulk X-list: linux-mips This is a cryptographically signed message in MIME format. --------------ms020508000201000800020508 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Hi all, I am working on an AU1100 project and I found problems in some pre-production boards. When the boards are powered up without Ethernet cable plugged-in, and the Ethernet is initialized, it seems that the system gets a lot of 'rx interrupts' and stays almost all the time inside the Ethernet rx interrupt service routine. This horribly slows down everything and causes the watchdog to come up resetting the board. Tried to make some debugging, but don't understand why there are all those interrupts. If the system is powered up with the Ethernet cable connected to a simple hub (hub only, no other computers connected to the net) the problem does not occur. I have this problem on about 10% boards. The design is based on AMD Syrah reference schematics, the kernel is 2.4.21-pre4. Searching with oscilloscope there is no apparent 'hardware' difference between a 'bad' board and a good one. Any suggestions ? Thanks, regards Lucio Dona' --------------ms020508000201000800020508 Content-Type: application/x-pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExCzAJBgUrDgMCGgUAMIAGCSqGSIb3DQEHAQAAoIIQEjCC BIowggNyoAMCAQICECf06hH0eobEbp27bqkXBwcwDQYJKoZIhvcNAQEFBQAwbzELMAkGA1UE BhMCU0UxFDASBgNVBAoTC0FkZFRydXN0IEFCMSYwJAYDVQQLEx1BZGRUcnVzdCBFeHRlcm5h bCBUVFAgTmV0d29yazEiMCAGA1UEAxMZQWRkVHJ1c3QgRXh0ZXJuYWwgQ0EgUm9vdDAeFw0w NTA2MDcwODA5MTBaFw0yMDA1MzAxMDQ4MzhaMIGuMQswCQYDVQQGEwJVUzELMAkGA1UECBMC VVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4wHAYDVQQKExVUaGUgVVNFUlRSVVNUIE5l dHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNlcnRydXN0LmNvbTE2MDQGA1UEAxMtVVRO LVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRpb24gYW5kIEVtYWlsMIIBIjANBgkqhkiG 9w0BAQEFAAOCAQ8AMIIBCgKCAQEAsjmFpPJ9q0E7YkY3rs3BYHW8OWX5ShpHornMSMxqmNVN NRm5pELlzkniii8efNIxB8dOtINknS4p1aJkxIW9hVE1eaROaJB7HHqkkqgX8pgV8pPMyaQy lbsMTzC9mKALi+VuG6JG+ni8om+rWV6lL8/K2m2qL+usobNqqrcuZzWLeeEeaYji5kbNoKXq vgvOdjp6Dpvq/NonWz1zHyLmSGHGTPNpsaguG7bUMSAsvIKKjqQOpdeJQ/wWWq8dcdcRWdq6 hw2v+vPhwvCkxWeM1tZUOt4KpLoDd7NlyP0e03RiqhjKaJMeoYV+9Udly/hNVyh00jT/MLbu 9mIwFIws6wIDAQABo4HhMIHeMB8GA1UdIwQYMBaAFK29mHo0tCb3+sQmVO8DveAky1QaMB0G A1UdDgQWBBSJgmd9xJ0mcABLtFBIfN49rgRufTAOBgNVHQ8BAf8EBAMCAQYwDwYDVR0TAQH/ BAUwAwEB/zB7BgNVHR8EdDByMDigNqA0hjJodHRwOi8vY3JsLmNvbW9kb2NhLmNvbS9BZGRU cnVzdEV4dGVybmFsQ0FSb290LmNybDA2oDSgMoYwaHR0cDovL2NybC5jb21vZG8ubmV0L0Fk ZFRydXN0RXh0ZXJuYWxDQVJvb3QuY3JsMA0GCSqGSIb3DQEBBQUAA4IBAQAZ2IkRbyispgCi 54fBm5AD236hEv0e8+LwAamUVEJrmgnEoG3XkJIEA2Z5Q3H8+G+v23ZF4jcaPd3kWQR4rBz0 g0bzes9bhHIt5UbBuhgRKfPLSXmHPLptBZ2kbWhPrXIUNqi5sf2/z3/wpGqUNVCPz4FtVbHd WTBK322gnGQfSXzvNrv042n0+DmPWq1LhTq3Du3Tzw1EovsEv+QvcI4l+1pUBrPQxLxtjftz Mizpm4QkLdZ/kXpoAlAfDj9N6cz1u2fo3BwuO/xOzf4CjuOoEwqlJkRl6RDyTVKnrtw+ymsy XEFs/vVdoOr/0fqbhlhtPZZH5f4ulQTCAMyOofK7MIIFvjCCBKagAwIBAgIQIItj0veEaiqr F3/W6viitTANBgkqhkiG9w0BAQUFADCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbDAeFw0wNjA5MjEwMDAwMDBa Fw0wNzA5MjEyMzU5NTlaMIHYMTUwMwYDVQQLEyxDb21vZG8gVHJ1c3QgTmV0d29yayAtIFBF UlNPTkEgTk9UIFZBTElEQVRFRDFGMEQGA1UECxM9VGVybXMgYW5kIENvbmRpdGlvbnMgb2Yg dXNlOiBodHRwOi8vd3d3LmNvbW9kby5uZXQvcmVwb3NpdG9yeTEfMB0GA1UECxMWKGMpMjAw MyBDb21vZG8gTGltaXRlZDEUMBIGA1UEAxMLTHVjaW8gRG9uYScxIDAeBgkqhkiG9w0BCQEW EW1lbW9yeWxvc3RAdGluLml0MIGfMA0GCSqGSIb3DQEBAQUAA4GNADCBiQKBgQDjcc2kiEuz PE+Uynvp8Hm1pcHM5SxPC6AFy8hNBIYwvLM/HAMikqzOaAm0xpCqWd3OGnCLenxxzcevIsuA ILJWv+bqL4Ydq33hpkN2T40lVWnwFDvPpMpiYx5dJYNSqBvbClBE4q45RYvWojbHm6Sgz6rj sK7Cb9bdJm7ZSTnEzQIDAQABo4ICLjCCAiowHwYDVR0jBBgwFoAUiYJnfcSdJnAAS7RQSHze Pa4Ebn0wHQYDVR0OBBYEFGd07JU5fNv5IPhfGf4kCtqeCUIOMA4GA1UdDwEB/wQEAwIFoDAM BgNVHRMBAf8EAjAAMCAGA1UdJQQZMBcGCCsGAQUFBwMEBgsrBgEEAbIxAQMFAjARBglghkgB hvhCAQEEBAMCBSAwRgYDVR0gBD8wPTA7BgwrBgEEAbIxAQIBAQEwKzApBggrBgEFBQcCARYd aHR0cHM6Ly9zZWN1cmUuY29tb2RvLm5ldC9DUFMwgaUGA1UdHwSBnTCBmjBMoEqgSIZGaHR0 cDovL2NybC5jb21vZG9jYS5jb20vVVROLVVTRVJGaXJzdC1DbGllbnRBdXRoZW50aWNhdGlv bmFuZEVtYWlsLmNybDBKoEigRoZEaHR0cDovL2NybC5jb21vZG8ubmV0L1VUTi1VU0VSRmly c3QtQ2xpZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwgYYGCCsGAQUFBwEBBHoweDA7 BggrBgEFBQcwAoYvaHR0cDovL2NydC5jb21vZG9jYS5jb20vVVROQWRkVHJ1c3RDbGllbnRD QS5jcnQwOQYIKwYBBQUHMAKGLWh0dHA6Ly9jcnQuY29tb2RvLm5ldC9VVE5BZGRUcnVzdENs aWVudENBLmNydDAcBgNVHREEFTATgRFtZW1vcnlsb3N0QHRpbi5pdDANBgkqhkiG9w0BAQUF AAOCAQEAWllXFs20b+3qhf/gPEadCka1eDk1MBZ8JZzyJI+a+Gpcmxfwemzw9C01kSFElBJr eP5NNyaSWmAoSPb19QmEYxe0KfMrEjt/HemNBlLNxwzqKbQFO3U5289IgLq28mEFtQluNbkd Lq0wCNg0OmntkaN0LwAYoHlacSEHj/Tei/siMJvVQgPO8uBRSwvkZoTPfHDE4MuiQcyYQUX8 ARjSYjDeSpcJtLiFWFD6lL8MmlXq/rSvtYILRNSnxPhvF3mD8ancgBPTiK2eYaPX4exiYKgu W98ig74wU/xByfMqd3xD2y7iHztiBO7AaqhVugiEuVxx2Db+rXeXlsH7AxnOvzCCBb4wggSm oAMCAQICECCLY9L3hGoqqxd/1ur4orUwDQYJKoZIhvcNAQEFBQAwga4xCzAJBgNVBAYTAlVT MQswCQYDVQQIEwJVVDEXMBUGA1UEBxMOU2FsdCBMYWtlIENpdHkxHjAcBgNVBAoTFVRoZSBV U0VSVFJVU1QgTmV0d29yazEhMB8GA1UECxMYaHR0cDovL3d3dy51c2VydHJ1c3QuY29tMTYw NAYDVQQDEy1VVE4tVVNFUkZpcnN0LUNsaWVudCBBdXRoZW50aWNhdGlvbiBhbmQgRW1haWww HhcNMDYwOTIxMDAwMDAwWhcNMDcwOTIxMjM1OTU5WjCB2DE1MDMGA1UECxMsQ29tb2RvIFRy dXN0IE5ldHdvcmsgLSBQRVJTT05BIE5PVCBWQUxJREFURUQxRjBEBgNVBAsTPVRlcm1zIGFu ZCBDb25kaXRpb25zIG9mIHVzZTogaHR0cDovL3d3dy5jb21vZG8ubmV0L3JlcG9zaXRvcnkx HzAdBgNVBAsTFihjKTIwMDMgQ29tb2RvIExpbWl0ZWQxFDASBgNVBAMTC0x1Y2lvIERvbmEn MSAwHgYJKoZIhvcNAQkBFhFtZW1vcnlsb3N0QHRpbi5pdDCBnzANBgkqhkiG9w0BAQEFAAOB jQAwgYkCgYEA43HNpIhLszxPlMp76fB5taXBzOUsTwugBcvITQSGMLyzPxwDIpKszmgJtMaQ qlndzhpwi3p8cc3HryLLgCCyVr/m6i+GHat94aZDdk+NJVVp8BQ7z6TKYmMeXSWDUqgb2wpQ ROKuOUWL1qI2x5ukoM+q47Cuwm/W3SZu2Uk5xM0CAwEAAaOCAi4wggIqMB8GA1UdIwQYMBaA FImCZ33EnSZwAEu0UEh83j2uBG59MB0GA1UdDgQWBBRndOyVOXzb+SD4Xxn+JAranglCDjAO BgNVHQ8BAf8EBAMCBaAwDAYDVR0TAQH/BAIwADAgBgNVHSUEGTAXBggrBgEFBQcDBAYLKwYB BAGyMQEDBQIwEQYJYIZIAYb4QgEBBAQDAgUgMEYGA1UdIAQ/MD0wOwYMKwYBBAGyMQECAQEB MCswKQYIKwYBBQUHAgEWHWh0dHBzOi8vc2VjdXJlLmNvbW9kby5uZXQvQ1BTMIGlBgNVHR8E gZ0wgZowTKBKoEiGRmh0dHA6Ly9jcmwuY29tb2RvY2EuY29tL1VUTi1VU0VSRmlyc3QtQ2xp ZW50QXV0aGVudGljYXRpb25hbmRFbWFpbC5jcmwwSqBIoEaGRGh0dHA6Ly9jcmwuY29tb2Rv Lm5ldC9VVE4tVVNFUkZpcnN0LUNsaWVudEF1dGhlbnRpY2F0aW9uYW5kRW1haWwuY3JsMIGG BggrBgEFBQcBAQR6MHgwOwYIKwYBBQUHMAKGL2h0dHA6Ly9jcnQuY29tb2RvY2EuY29tL1VU TkFkZFRydXN0Q2xpZW50Q0EuY3J0MDkGCCsGAQUFBzAChi1odHRwOi8vY3J0LmNvbW9kby5u ZXQvVVROQWRkVHJ1c3RDbGllbnRDQS5jcnQwHAYDVR0RBBUwE4ERbWVtb3J5bG9zdEB0aW4u aXQwDQYJKoZIhvcNAQEFBQADggEBAFpZVxbNtG/t6oX/4DxGnQpGtXg5NTAWfCWc8iSPmvhq XJsX8Hps8PQtNZEhRJQSa3j+TTcmklpgKEj29fUJhGMXtCnzKxI7fx3pjQZSzccM6im0BTt1 OdvPSIC6tvJhBbUJbjW5HS6tMAjYNDpp7ZGjdC8AGKB5WnEhB4/03ov7IjCb1UIDzvLgUUsL 5GaEz3xwxODLokHMmEFF/AEY0mIw3kqXCbS4hVhQ+pS/DJpV6v60r7WCC0TUp8T4bxd5g/Gp 3IAT04itnmGj1+HsYmCoLlvfIoO+MFP8QcnzKnd8Q9su4h87YgTuwGqoVboIhLlccdg2/q13 l5bB+wMZzr8xggPPMIIDywIBATCBwzCBrjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcw FQYDVQQHEw5TYWx0IExha2UgQ2l0eTEeMBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3Jr MSEwHwYDVQQLExhodHRwOi8vd3d3LnVzZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VS Rmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0aW9uIGFuZCBFbWFpbAIQIItj0veEaiqrF3/W6vii tTAJBgUrDgMCGgUAoIICYTAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJ BTEPFw0wNzAyMTMwNjAzNDZaMCMGCSqGSIb3DQEJBDEWBBTWpbwZ6k4Y4Fk3XwOwY4GvRJ5K gzBSBgkqhkiG9w0BCQ8xRTBDMAoGCCqGSIb3DQMHMA4GCCqGSIb3DQMCAgIAgDANBggqhkiG 9w0DAgIBQDAHBgUrDgMCBzANBggqhkiG9w0DAgIBKDCB1AYJKwYBBAGCNxAEMYHGMIHDMIGu MQswCQYDVQQGEwJVUzELMAkGA1UECBMCVVQxFzAVBgNVBAcTDlNhbHQgTGFrZSBDaXR5MR4w HAYDVQQKExVUaGUgVVNFUlRSVVNUIE5ldHdvcmsxITAfBgNVBAsTGGh0dHA6Ly93d3cudXNl cnRydXN0LmNvbTE2MDQGA1UEAxMtVVROLVVTRVJGaXJzdC1DbGllbnQgQXV0aGVudGljYXRp b24gYW5kIEVtYWlsAhAgi2PS94RqKqsXf9bq+KK1MIHWBgsqhkiG9w0BCRACCzGBxqCBwzCB rjELMAkGA1UEBhMCVVMxCzAJBgNVBAgTAlVUMRcwFQYDVQQHEw5TYWx0IExha2UgQ2l0eTEe MBwGA1UEChMVVGhlIFVTRVJUUlVTVCBOZXR3b3JrMSEwHwYDVQQLExhodHRwOi8vd3d3LnVz ZXJ0cnVzdC5jb20xNjA0BgNVBAMTLVVUTi1VU0VSRmlyc3QtQ2xpZW50IEF1dGhlbnRpY2F0 aW9uIGFuZCBFbWFpbAIQIItj0veEaiqrF3/W6viitTANBgkqhkiG9w0BAQEFAASBgHsLeyiH iHfxJSFkIovKMEDIW5QEfM6977FAT7w2bMelHLW5M7SZQQpEbWRJbQSgr48hINMFgPqQJ235 eri65ZN7qy5sF835KBiqT19q1boXv1apRwxodcNnHTR2rSJpRrA/RI524znygaWpD7xM8qA+ JKg5REOeGzf86nB8H/O8AAAAAAAA --------------ms020508000201000800020508-- From michael@cubic.org Tue Feb 13 07:52:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 07:52:58 +0000 (GMT) Received: from roasted.cubic.org ([193.108.181.130]:21670 "EHLO roasted.cubic.org") by ftp.linux-mips.org with ESMTP id S20038718AbXBMHwu (ORCPT ); Tue, 13 Feb 2007 07:52:50 +0000 Received: from c145138.adsl.hansenet.de ([213.39.145.138] helo=cubic.org) by roasted.cubic.org with asmtp (TLSv1:RC4-MD5:128) (Exim 3.36 #1) id 1HGsPw-0005gA-00 for linux-mips@linux-mips.org; Tue, 13 Feb 2007 08:49:36 +0100 Message-ID: <45D16D8B.40401@cubic.org> Date: Tue, 13 Feb 2007 08:49:31 +0100 From: Michael Stickel User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225 X-Accept-Language: en-us, en MIME-Version: 1.0 To: linux-mips@linux-mips.org Subject: Re: AU1100 Ethernet problems References: <45D154C2.9030809@tin.it> In-Reply-To: <45D154C2.9030809@tin.it> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14057 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: michael@cubic.org Precedence: bulk X-list: linux-mips Lucio Dona' wrote: > When the boards are powered up without Ethernet cable plugged-in, and > the Ethernet is initialized, it seems that the system gets a lot of > 'rx interrupts' and stays almost all the time inside the Ethernet rx > interrupt service routine. > This horribly slows down everything and causes the watchdog to come up > resetting the board. > > Tried to make some debugging, but don't understand why there are all > those interrupts. > > If the system is powered up with the Ethernet cable connected to a > simple hub (hub only, no other computers connected to the net) the > problem does not occur. > > I have this problem on about 10% boards. > The design is based on AMD Syrah reference schematics, the kernel is > 2.4.21-pre4. Searching with oscilloscope there is no apparent > 'hardware' difference between a 'bad' board and a good one. If this is on 10% of the boards I would say it is a production problem. What PHY do you use and is it properly reseted? Is there any soldering problem with the PHY. Does it have a ground pad under the case and is this pad well soldered? Regards, Michael From huang.ying.caritas@gmail.com Tue Feb 13 08:27:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 08:27:36 +0000 (GMT) Received: from wx-out-0506.google.com ([66.249.82.239]:8601 "EHLO wx-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038861AbXBMI1c (ORCPT ); Tue, 13 Feb 2007 08:27:32 +0000 Received: by wx-out-0506.google.com with SMTP id t14so2140943wxc for ; Tue, 13 Feb 2007 00:26:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q53UC2RKUToXBJBM+nMBiCIp71bkQib90Y5UrLjErvky46E94eGIydQjiVyNO1atCXKf5IuafGP3c8FAZQALAaptvIKDORc/t79g6CyDERTjwzKRlEW5xL9xz+RQ6eURxmc4DaZUSdUgWdBu/2V6jlU6UFynHzurIWtDX8Nru90= Received: by 10.90.68.15 with SMTP id q15mr18684850aga.1171355191196; Tue, 13 Feb 2007 00:26:31 -0800 (PST) Received: by 10.90.51.6 with HTTP; Tue, 13 Feb 2007 00:26:31 -0800 (PST) Message-ID: <851fc09e0702130026l1f63ece3h94197635068673ce@mail.gmail.com> Date: Tue, 13 Feb 2007 16:26:31 +0800 From: "huang ying" To: "Wim Vander Schelden" Subject: Re: Linux on the MobilePro 7xx Cc: linux-mips@linux-mips.org In-Reply-To: <45C289C9.3010409@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45C289C9.3010409@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14058 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: huang.ying.caritas@gmail.com Precedence: bulk X-list: linux-mips Hi, I have ported Linux 2.6 to my MobilePro 800, which uses a VR4121 too. I think most driver can be used for MobilePro 770 too. The source code and simple document can be found in: http://linux-mcr700.sourceforge.net Hope helpful to you. Best Regards, Huang Ying From vagabon.xyz@gmail.com Tue Feb 13 08:28:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 08:28:26 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.239]:42140 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038898AbXBMI2W (ORCPT ); Tue, 13 Feb 2007 08:28:22 +0000 Received: by qb-out-0506.google.com with SMTP id e12so714720qba for ; Tue, 13 Feb 2007 00:27:21 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=H2he077f/C63Emob5alCc2T3DWI4iycOEKTca4rNVrq1qi4dMFNHyGkt41B4vTw9YsoWQ/cLi9xxvVvVHSeYCExs7jX6apBMEWBqlaPrNkVenAptqWoBW9g3pfcpY7wtcZqf5F31RHDkM6s+KUGCHevNrFZRTc6dT4milY/B8Ds= Received: by 10.115.47.1 with SMTP id z1mr7469474waj.1171355240847; Tue, 13 Feb 2007 00:27:20 -0800 (PST) Received: by 10.114.136.11 with HTTP; Tue, 13 Feb 2007 00:27:20 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 09:27:20 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: struct sigcontext for N32 userland Cc: linux-mips@linux-mips.org In-Reply-To: <20070213.005113.89067116.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070213.005113.89067116.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14059 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/12/07, Atsushi Nemoto wrote: > If N32 userland refers asm-mips/sigcontext.h, struct sigcontext cause > some troubles. > > #if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > > struct sigcontext { > unsigned long sc_regs[32]; > ... > > > The kernel use 64-bit for sc_regs[0], and both N32/N64 userland > expects it was 64-bit. But size of 'long' on N32 is actually 32-bit. > So this definition make some confusion. > > glibc has its own sigcontext.h and it uses 'unsigned long long' for > sc_regs, so no real problem with glibc. > Just out of curiosity, for what purpose does the glibc use sigcontext ? -- Franck From vagabon.xyz@gmail.com Tue Feb 13 09:20:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 09:20:32 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.234]:45365 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039024AbXBMJUC (ORCPT ); Tue, 13 Feb 2007 09:20:02 +0000 Received: by hu-out-0506.google.com with SMTP id 22so1062366hug for ; Tue, 13 Feb 2007 01:19:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:from; b=Nhq8/5drnSC+c0XxpzH0QARhh5E9/vqrle0s7y2hq8U4lFmypsq5Yq9dw48AhtJL0yJzQEMjcdPBPtbyL7oKHR0Bz4f8bSh2SS1BDrXkuOTUgXUTmX3+qdB5r8jfipVLjFvVcosunRxsAbHqZrFLo++C6ww7K9YgTlmbt80w6Pg= Received: by 10.48.202.14 with SMTP id z14mr518783nff.1171358340551; Tue, 13 Feb 2007 01:19:00 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id n23sm1886941nfc.2007.02.13.01.18.59; Tue, 13 Feb 2007 01:18:59 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 36A6C23F770; Tue, 13 Feb 2007 10:18:09 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org Subject: [RFC] Kill CONFIG_BUILD_ELF64 from Kconfig Date: Tue, 13 Feb 2007 10:18:06 +0100 Message-Id: <1171358289786-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14060 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi, This patchset results from the following thread we had a couple weeks ago: http://marc.theaimsgroup.com/?l=linux-mips&m=117000798317188&w=2 Once this patchset is applied, we do not need to configure CONFIG_BUILD_ELF64 manually. Instead, the makefile should do the right thing for us: - It passes '-msym32' switch to gcc according to the platform's load address. - We can still force Kbuild to not use '-msym32' whatever the value of the load address by passing "BUILD_ELF32=no" when invoking make. Patch #3 renames CONFIG_BUILD_ELF64 into CONFIG_64BIT_BUILD_ELF32. It simplifies the places where it's used. This patchset assumes that the compiler will fail if it doesn't support '-msym32' switch. Therefore we needn't to test gcc's version when testing CONFIG_64BIT_BUILD_ELF32 value. Please, consider. Franck --- arch/mips/Kconfig | 15 --------------- arch/mips/Makefile | 23 ++++++++++++++++++----- include/asm-mips/page.h | 2 +- include/asm-mips/pgtable-64.h | 2 +- include/asm-mips/stackframe.h | 12 ++++++------ 5 files changed, 26 insertions(+), 28 deletions(-) From vagabon.xyz@gmail.com Tue Feb 13 09:20:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 09:21:02 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.227]:45621 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039051AbXBMJUC (ORCPT ); Tue, 13 Feb 2007 09:20:02 +0000 Received: by hu-out-0506.google.com with SMTP id 22so1062368hug for ; Tue, 13 Feb 2007 01:19:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=poWLTNYSO/RAdSB5p00e+dbVS++c15WNQCQXcJdFoMowNJOs+VTML9ffhax72jhxkYyaFMBeQw4cG9q9upy4b2ptY6HO4CazBdxYwT/wget10oIsNZZI7XzhXBBXYtcjhAxo10MYd2TzraRAxa0LWoX0KcdDob7HW7nEiGPXtPg= Received: by 10.49.93.4 with SMTP id v4mr516513nfl.1171358341058; Tue, 13 Feb 2007 01:19:01 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id l21sm1886432nfc.2007.02.13.01.18.59; Tue, 13 Feb 2007 01:18:59 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 5EEC323F76A; Tue, 13 Feb 2007 10:18:10 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org Subject: [PATCH 1/3] Remove '-mno-explicit-relocs' option when CONFIG_BUILD_ELF64 Date: Tue, 13 Feb 2007 10:18:07 +0100 Message-Id: <11713582891191-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171358289786-git-send-email-fbuihuu@gmail.com> References: <1171358289786-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14061 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This patch removes '-mno-explicit-relocs' usage when CONFIG_BUILD_ELF64 is set since this option was only required with the old hack to truncate addresses at the assembly level where "-mabi=64 -Wa,-mabi=32" was used. This should yield a small code size improvement for inline assembly, where the R constraint is used. The idea is coming from Maciej . Signed-off-by: Franck Bui-Huu --- arch/mips/Makefile | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index c68b5d3..4240ca1 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -60,9 +60,7 @@ vmlinux-32 = vmlinux.32 vmlinux-64 = vmlinux cflags-y += -mabi=64 -ifdef CONFIG_BUILD_ELF64 -cflags-y += $(call cc-option,-mno-explicit-relocs) -else +ifndef CONFIG_BUILD_ELF64 cflags-y += $(call cc-option,-msym32) endif endif -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Tue Feb 13 09:21:25 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 09:21:28 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.224]:46133 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039054AbXBMJUC (ORCPT ); Tue, 13 Feb 2007 09:20:02 +0000 Received: by hu-out-0506.google.com with SMTP id 22so1062371hug for ; Tue, 13 Feb 2007 01:19:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=BTxMnELQ3e/81dsIlPfVndlJP9t5iZvgi5e86pfaKlpJbzhWbr+D04AHvuLQZW39edzeERZFEF75vLXzQyhqkestVaFbGGjJTwMkN7U9zYAkTMQsrRAL/qfeGUZbTsZoW6zZWVD3mR2WFIlcurCeMUOuw62cqxHHetJfujmYt2w= Received: by 10.48.246.4 with SMTP id t4mr517696nfh.1171358341171; Tue, 13 Feb 2007 01:19:01 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id m15sm1911029nfc.2007.02.13.01.18.59; Tue, 13 Feb 2007 01:19:00 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 6D94523F76E; Tue, 13 Feb 2007 10:18:10 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org Subject: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Date: Tue, 13 Feb 2007 10:18:08 +0100 Message-Id: <11713582901742-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171358289786-git-send-email-fbuihuu@gmail.com> References: <1171358289786-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14062 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu We do not rely on user anymore to setup this config correctly. Instead we make our choice depending on the load address. If we want to force Kbuild to use ELF64 format whatever the load address we can still do: $ make BUILD_ELF32=no Signed-off-by: Franck Bui-Huu --- arch/mips/Kconfig | 15 --------------- arch/mips/Makefile | 23 ++++++++++++++++++++--- 2 files changed, 20 insertions(+), 18 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 54acbf5..89020b6 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2009,21 +2009,6 @@ source "fs/Kconfig.binfmt" config TRAD_SIGNALS bool -config BUILD_ELF64 - bool "Use 64-bit ELF format for building" - depends on 64BIT - help - A 64-bit kernel is usually built using the 64-bit ELF binary object - format as it's one that allows arbitrary 64-bit constructs. For - kernels that are loaded within the KSEG compatibility segments the - 32-bit ELF format can optionally be used resulting in a somewhat - smaller binary, but this option is not explicitly supported by the - toolchain and since binutils 2.14 it does not even work at all. - - Say Y to use the 64-bit format or N to use the 32-bit one. - - If unsure say Y. - config BINFMT_IRIX bool "Include IRIX binary compatibility" depends on CPU_BIG_ENDIAN && 32BIT && BROKEN diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 4240ca1..626771c 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -60,9 +60,6 @@ vmlinux-32 = vmlinux.32 vmlinux-64 = vmlinux cflags-y += -mabi=64 -ifndef CONFIG_BUILD_ELF64 -cflags-y += $(call cc-option,-msym32) -endif endif @@ -614,6 +611,26 @@ else JIFFIES = jiffies_64 endif +# +# Automatically detect the build format. By default we choose +# the elf format according to the load address. +# We can always force a build with a 64-bits symbol format by +# passing 'BUILD_ELF32=no' option to the make's command line. +# +ifdef CONFIG_64BIT + ifndef BUILD_ELF32 + ifeq ($(shell expr $(load-y) \< 0xffffffff80000000), 0) + BUILD_ELF32 = y + endif + endif + + ifeq ("$(BUILD_ELF32)", "y") + cflags-y += -msym32 + else + cflags-y += -DCONFIG_BUILD_ELF64 + endif +endif # CONFIG_64BIT + AFLAGS += $(cflags-y) CFLAGS += $(cflags-y) -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Tue Feb 13 09:21:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 09:21:58 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.231]:46901 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039097AbXBMJUC (ORCPT ); Tue, 13 Feb 2007 09:20:02 +0000 Received: by hu-out-0506.google.com with SMTP id 22so1062376hug for ; Tue, 13 Feb 2007 01:19:01 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=fGcbNk+aNmpK8bhr6h0o5JH5DBUUZJC5RnIMMHg6GjOBUWPTcyBJLeNuUmNyDIj4LUv0WKrj+d5kl/dGodiRykA/BAeD37Xle17B0JEGkM3GVbFUOULwnD5TRqa8bomo+5/5NVucXxRd5pG3jvArgcFsfcqdPv2Fmm8IaNu5jHc= Received: by 10.48.162.15 with SMTP id k15mr537722nfe.1171358341350; Tue, 13 Feb 2007 01:19:01 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id l27sm1895034nfa.2007.02.13.01.18.59; Tue, 13 Feb 2007 01:19:00 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 7FF9023F76F; Tue, 13 Feb 2007 10:18:10 +0100 (CET) To: ralf@linux-mips.org Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org Subject: [PATCH 3/3] Rename CONFIG_BUILD_ELF64 into CONFIG_64BIT_BUILD_ELF32 Date: Tue, 13 Feb 2007 10:18:09 +0100 Message-Id: <11713582901252-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171358289786-git-send-email-fbuihuu@gmail.com> References: <1171358289786-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14063 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu Signed-off-by: Franck Bui-Huu --- arch/mips/Makefile | 6 ++---- include/asm-mips/page.h | 2 +- include/asm-mips/pgtable-64.h | 2 +- include/asm-mips/stackframe.h | 12 ++++++------ 4 files changed, 10 insertions(+), 12 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 626771c..fa08d07 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -625,11 +625,9 @@ ifdef CONFIG_64BIT endif ifeq ("$(BUILD_ELF32)", "y") - cflags-y += -msym32 - else - cflags-y += -DCONFIG_BUILD_ELF64 + cflags-y += -msym32 -DCONFIG_64BIT_BUILD_ELF32 endif -endif # CONFIG_64BIT +endif AFLAGS += $(cflags-y) CFLAGS += $(cflags-y) diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h index d3fbd83..d37a24c 100644 --- a/include/asm-mips/page.h +++ b/include/asm-mips/page.h @@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; } pgprot_t; /* * __pa()/__va() should be used only during mem init. */ -#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64) +#ifdef CONFIG_64BIT_BUILD_ELF32 #define __pa_page_offset(x) ((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0) #else #define __pa_page_offset(x) PAGE_OFFSET diff --git a/include/asm-mips/pgtable-64.h b/include/asm-mips/pgtable-64.h index a5b1871..55be7b5 100644 --- a/include/asm-mips/pgtable-64.h +++ b/include/asm-mips/pgtable-64.h @@ -104,7 +104,7 @@ #define VMALLOC_START MAP_BASE #define VMALLOC_END \ (VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE) -#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \ +#if defined(CONFIG_MODULES) && defined(CONFIG_64BIT_BUILD_ELF32) && \ VMALLOC_START != CKSSEG /* Load modules into 32bit-compatible segment. */ #define MODULE_START CKSSEG diff --git a/include/asm-mips/stackframe.h b/include/asm-mips/stackframe.h index 1fae5dc..917ffa5 100644 --- a/include/asm-mips/stackframe.h +++ b/include/asm-mips/stackframe.h @@ -70,14 +70,14 @@ #else MFC0 k0, CP0_CONTEXT #endif -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4) +#if defined(CONFIG_32BIT) || defined(CONFIG_64BIT_BUILD_ELF32) + lui k1, %hi(kernelsp) +#else lui k1, %highest(kernelsp) daddiu k1, %higher(kernelsp) dsll k1, 16 daddiu k1, %hi(kernelsp) dsll k1, 16 -#else - lui k1, %hi(kernelsp) #endif LONG_SRL k0, PTEBASE_SHIFT LONG_ADDU k1, k0 @@ -95,14 +95,14 @@ .endm #else .macro get_saved_sp /* Uniprocessor variation */ -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4) +#if defined(CONFIG_32BIT) || defined(CONFIG_64BIT_BUILD_ELF32) + lui k1, %hi(kernelsp) +#else lui k1, %highest(kernelsp) daddiu k1, %higher(kernelsp) dsll k1, k1, 16 daddiu k1, %hi(kernelsp) dsll k1, k1, 16 -#else - lui k1, %hi(kernelsp) #endif LONG_L k1, %lo(kernelsp)(k1) .endm -- 1.4.4.3.ge6d4 From ralf@linux-mips.org Tue Feb 13 11:38:30 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 11:38:32 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:30928 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039106AbXBMLia (ORCPT ); Tue, 13 Feb 2007 11:38:30 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DBcRqQ005378; Tue, 13 Feb 2007 11:38:27 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DBcQSg005377; Tue, 13 Feb 2007 11:38:26 GMT Date: Tue, 13 Feb 2007 11:38:26 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: struct sigcontext for N32 userland Message-ID: <20070213113826.GA4569@linux-mips.org> References: <20070213.005113.89067116.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14064 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 13, 2007 at 09:27:20AM +0100, Franck Bui-Huu wrote: > On 2/12/07, Atsushi Nemoto wrote: > >If N32 userland refers asm-mips/sigcontext.h, struct sigcontext cause > >some troubles. > > > >#if _MIPS_SIM == _MIPS_SIM_ABI64 || _MIPS_SIM == _MIPS_SIM_NABI32 > > > >struct sigcontext { > > unsigned long sc_regs[32]; > >... > > > > > >The kernel use 64-bit for sc_regs[0], and both N32/N64 userland > >expects it was 64-bit. But size of 'long' on N32 is actually 32-bit. > >So this definition make some confusion. > > > >glibc has its own sigcontext.h and it uses 'unsigned long long' for > >sc_regs, so no real problem with glibc. Looks like a case for __u32, __u64 then. > Just out of curiosity, for what purpose does the glibc use sigcontext ? Afair it doesn't use sigcontext itself but makes it available to applications through . Typical users are virtual machines, JITs, debuggers, user space virtual memory. Ralf From ralf@linux-mips.org Tue Feb 13 11:49:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 11:49:56 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:36009 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039155AbXBMLtz (ORCPT ); Tue, 13 Feb 2007 11:49:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DBnYdY005887; Tue, 13 Feb 2007 11:49:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1D2PmB2018574; Tue, 13 Feb 2007 02:25:48 GMT Date: Tue, 13 Feb 2007 02:25:48 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: linux-mips@linux-mips.org, vagabon.xyz@gmail.com Subject: Re: [PATCH] fix irq handling of DECstations Message-ID: <20070213022548.GB25323@linux-mips.org> References: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14065 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Mon, Feb 12, 2007 at 11:48:26PM +0900, Atsushi Nemoto wrote: > It looks 2.6.19 or 2.6.20 does not work on DECStations. Applied. Thanks, Ralf From ralf@linux-mips.org Tue Feb 13 11:50:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 11:50:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:36265 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039157AbXBMLtz (ORCPT ); Tue, 13 Feb 2007 11:49:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DBnYda005887; Tue, 13 Feb 2007 11:49:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1D25u0o024231; Tue, 13 Feb 2007 02:05:56 GMT Date: Tue, 13 Feb 2007 02:05:56 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, fbuihuu@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Message-ID: <20070213020556.GA5875@linux-mips.org> References: <20070209210014.GA26939@linux-mips.org> <20070212140459.GA9679@linux-mips.org> <20070213.002545.03977174.anemo@mba.ocn.ne.jp> <20070213014345.GA30988@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070213014345.GA30988@linux-mips.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14066 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 13, 2007 at 01:43:45AM +0000, Ralf Baechle wrote: > Well, I reverted that the old state of a warning is definately preferable > until we found a proper solution. Type-punning should do the trick. Ralf Signed-off-by: Ralf Baechle diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index c12ebc5..36b3a42 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -265,7 +265,10 @@ do { \ */ #define __get_user_asm_ll32(val, addr) \ { \ - unsigned long long __gu_tmp; \ + union { \ + unsigned long long l; \ + __typeof__(*(addr)) t; \ + } __gu_tmp; \ \ __asm__ __volatile__( \ "1: lw %1, (%3) \n" \ @@ -281,9 +284,10 @@ do { \ " " __UA_ADDR " 1b, 4b \n" \ " " __UA_ADDR " 2b, 4b \n" \ " .previous \n" \ - : "=r" (__gu_err), "=&r" (__gu_tmp) \ + : "=r" (__gu_err), "=&r" (__gu_tmp.l) \ : "0" (0), "r" (addr), "i" (-EFAULT)); \ - (val) = (__typeof__(*(addr))) __gu_tmp; \ + \ + (val) = __gu_tmp.t; \ } /* From ralf@linux-mips.org Tue Feb 13 11:50:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 11:50:48 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:36521 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039161AbXBMLtz (ORCPT ); Tue, 13 Feb 2007 11:49:55 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DBnYdc005887; Tue, 13 Feb 2007 11:49:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1D1dWTg030973; Tue, 13 Feb 2007 01:39:32 GMT Date: Tue, 13 Feb 2007 01:39:32 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, Franck Bui-Huu Subject: Re: [PATCH 2/3] signals: make common _BLOCKABLE macro Message-ID: <20070213013932.GA30432@linux-mips.org> References: <1171033658561-git-send-email-fbuihuu@gmail.com> <11710336593668-git-send-email-fbuihuu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11710336593668-git-send-email-fbuihuu@gmail.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14067 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 09, 2007 at 04:07:37PM +0100, Franck Bui-Huu wrote: Thanks, applied. Ralf From ralf@linux-mips.org Tue Feb 13 11:51:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 11:51:14 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:57770 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039157AbXBMLur (ORCPT ); Tue, 13 Feb 2007 11:50:47 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DBnYde005887; Tue, 13 Feb 2007 11:49:55 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1D1hjV1031216; Tue, 13 Feb 2007 01:43:45 GMT Date: Tue, 13 Feb 2007 01:43:45 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, fbuihuu@gmail.com, linux-mips@linux-mips.org Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Message-ID: <20070213014345.GA30988@linux-mips.org> References: <20070209210014.GA26939@linux-mips.org> <20070212140459.GA9679@linux-mips.org> <20070213.002545.03977174.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070213.002545.03977174.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14068 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 13, 2007 at 12:25:45AM +0900, Atsushi Nemoto wrote: > On Mon, 12 Feb 2007 14:04:59 +0000, Ralf Baechle wrote: > > > How about this instead ? > > > > Won't work for a pointer to some const thing. > > And recent commit 4ed3a77f38c023658784804cb39a7ce18063dc88 reverts > commit 3218357c94af92478ef39163163a81e654385320. > > Round and round and round and ... Well, I reverted that the old state of a warning is definately preferable until we found a proper solution. Ralf From ralf@linux-mips.org Tue Feb 13 13:32:53 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 13:32:54 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:32994 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039250AbXBMNcx (ORCPT ); Tue, 13 Feb 2007 13:32:53 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DDWqWT018662; Tue, 13 Feb 2007 13:32:52 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DDWpTI018661; Tue, 13 Feb 2007 13:32:51 GMT Date: Tue, 13 Feb 2007 13:32:51 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org Subject: More __get_user_asm_ll32 ... Message-ID: <20070213133251.GA7518@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14069 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips __get_user_asm_ll32 contains a junk move %0, $0 left over from an older version of the code. Ignoring fixups code and data this instruction inflates the normal path in __get_user() by 50% which may explain much of the size and performance you have meassures. It also always clears the error return, iow. __get_user_asm_ll32(..., &) would never have returned an error. ARGH. Ralf From vagabon.xyz@gmail.com Tue Feb 13 13:52:09 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 13:52:14 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.230]:25423 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039260AbXBMNwI (ORCPT ); Tue, 13 Feb 2007 13:52:08 +0000 Received: by hu-out-0506.google.com with SMTP id 22so1106330hug for ; Tue, 13 Feb 2007 05:51:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=rGxGpOtKYzbM2C83dHBMMfsrFxCXjI1eggUa04Wola49EeEkUA3JFE5WF3IU/R1P+UZYHYu7a0kbO6Y5qBuzIGwVBc/TpRcWbFjjtzEtTByur7DBc7E5a81xARgStHhsTFg27WejYfv+cefQnxZXq61fztMMZ6q0ok7EFTssCro= Received: by 10.82.114.3 with SMTP id m3mr10970511buc.1171374668401; Tue, 13 Feb 2007 05:51:08 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id m15sm2768771nfc.2007.02.13.05.51.06; Tue, 13 Feb 2007 05:51:07 -0800 (PST) Message-ID: <45D1C21A.9070801@innova-card.com> Date: Tue, 13 Feb 2007 14:50:18 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: Atsushi Nemoto , linux-mips@linux-mips.org, vagabon.xyz@gmail.com Subject: Re: [PATCH] fix irq handling of DECstations References: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> <20070213022548.GB25323@linux-mips.org> In-Reply-To: <20070213022548.GB25323@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14070 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > On Mon, Feb 12, 2007 at 11:48:26PM +0900, Atsushi Nemoto wrote: > >> It looks 2.6.19 or 2.6.20 does not work on DECStations. > > Applied. Thanks, > Hi Ralf, Since you applied Atsushi's patch, can you consider the following one ? thanks Franck -- >8 -- From: Franck Bui-Huu This patch makes these routines a lot more readable whatever the value of CONFIG_PREEMPT. When CONFIG_PREEMPT is not set, it also moves one branch instruction from ret_from_irq() to ret_from_exception(). Therefore we favour the return from irq case which should be more common than the other one. Acked-by: Atsushi Nemoto Signed-off-by: Franck Bui-Huu --- arch/mips/kernel/entry.S | 17 +++++++---------- 1 files changed, 7 insertions(+), 10 deletions(-) diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S index f10b6a1..c7429b2 100644 --- a/arch/mips/kernel/entry.S +++ b/arch/mips/kernel/entry.S @@ -21,24 +21,21 @@ #endif #ifndef CONFIG_PREEMPT - .macro preempt_stop - local_irq_disable - .endm #define resume_kernel restore_all +#else +#define __ret_from_irq ret_from_exception #endif .text .align 5 -FEXPORT(ret_from_irq) - LONG_S s0, TI_REGS($28) -#ifdef CONFIG_PREEMPT +#ifndef CONFIG_PREEMPT FEXPORT(ret_from_exception) -#else + local_irq_disable # preempt stop b _ret_from_irq -FEXPORT(ret_from_exception) - preempt_stop #endif -FEXPORT(_ret_from_irq) +FEXPORT(ret_from_irq) + LONG_S s0, TI_REGS($28) +FEXPORT(__ret_from_irq) LONG_L t0, PT_STATUS(sp) # returning to kernel mode? andi t0, t0, KU_USER beqz t0, resume_kernel -- 1.4.4.3.ge6d4 From anemo@mba.ocn.ne.jp Tue Feb 13 14:36:26 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 14:36:31 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:34045 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28573702AbXBMOg0 (ORCPT ); Tue, 13 Feb 2007 14:36:26 +0000 Received: from localhost (p7211-ipad32funabasi.chiba.ocn.ne.jp [221.189.139.211]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id BDF528908; Tue, 13 Feb 2007 23:35:05 +0900 (JST) Date: Tue, 13 Feb 2007 23:35:05 +0900 (JST) Message-Id: <20070213.233505.64804701.anemo@mba.ocn.ne.jp> To: djohnson+linux-mips@sw.starentnetworks.com Cc: linux-mips@linux-mips.org Subject: Re: problems booting sb1250, page fault issue? From: Atsushi Nemoto In-Reply-To: <17872.61204.190437.109367@zeus.sw.starentnetworks.com> References: <17869.2075.900049.547334@zeus.sw.starentnetworks.com> <20070211.010336.15248113.anemo@mba.ocn.ne.jp> <17872.61204.190437.109367@zeus.sw.starentnetworks.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14071 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Mon, 12 Feb 2007 17:49:56 -0500, Dave Johnson wrote: > I added both flush_data_cache_page to c-sb1.c and > __flush_icache_page() to flush_icache_page in cacheflush.h. > > With those, the page faults work correctly and booting seems to be > reliable on 2.6.18. I think the problem of c-sb1.c was fixed in lmo 2.6.18-stable branch. Could you try it? --- Atsushi Nemoto From ralf@linux-mips.org Tue Feb 13 15:27:18 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 15:27:20 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:13006 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28573708AbXBMP1S (ORCPT ); Tue, 13 Feb 2007 15:27:18 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DFRHX5005182; Tue, 13 Feb 2007 15:27:18 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DFRGuA005181; Tue, 13 Feb 2007 15:27:16 GMT Date: Tue, 13 Feb 2007 15:27:16 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH] fix irq handling of DECstations Message-ID: <20070213152716.GA4942@linux-mips.org> References: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> <20070213022548.GB25323@linux-mips.org> <45D1C21A.9070801@innova-card.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D1C21A.9070801@innova-card.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14072 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 13, 2007 at 02:50:18PM +0100, Franck Bui-Huu wrote: > This patch makes these routines a lot more readable whatever > the value of CONFIG_PREEMPT. Applied. Ralf From ralf@linux-mips.org Tue Feb 13 15:54:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 15:54:46 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:62620 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039260AbXBMPyo (ORCPT ); Tue, 13 Feb 2007 15:54:44 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DFsT9L008561; Tue, 13 Feb 2007 15:54:29 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DFsAbW008486; Tue, 13 Feb 2007 15:54:10 GMT Date: Tue, 13 Feb 2007 15:54:10 +0000 From: Ralf Baechle To: tigerand@gmail.com Cc: linux-mips@linux-mips.org Subject: Re: [PATCH] try#2 Fix non-SMP build Sibyte 1250 SOC, kernel linux-mips.git master Message-ID: <20070213155407.GA18617@linux-mips.org> References: <20070210013521.GA13917@onstor.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070210013521.GA13917@onstor.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14073 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 09, 2007 at 05:35:28PM -0800, tigerand@gmail.com wrote: Thanks, applied. Ralf From anemo@mba.ocn.ne.jp Tue Feb 13 16:07:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 16:07:45 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:35787 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039266AbXBMQHi (ORCPT ); Tue, 13 Feb 2007 16:07:38 +0000 Received: from localhost (p7211-ipad32funabasi.chiba.ocn.ne.jp [221.189.139.211]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id CBE46D31; Wed, 14 Feb 2007 01:06:15 +0900 (JST) Date: Wed, 14 Feb 2007 01:06:15 +0900 (JST) Message-Id: <20070214.010615.101715999.anemo@mba.ocn.ne.jp> To: ralf@linux-mips.org Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: More __get_user_asm_ll32 ... From: Atsushi Nemoto In-Reply-To: <20070213133251.GA7518@linux-mips.org> References: <20070213133251.GA7518@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14074 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Tue, 13 Feb 2007 13:32:51 +0000, Ralf Baechle wrote: > __get_user_asm_ll32 contains a junk move %0, $0 left over from an older > version of the code. Ignoring fixups code and data this instruction > inflates the normal path in __get_user() by 50% which may explain much of > the size and performance you have meassures. It also always clears > the error return, iow. __get_user_asm_ll32(..., &) > would never have returned an error. ARGH. Why is it clears the error return? The "3:" label is just after the junk move. --- Atsushi Nemoto From ralf@linux-mips.org Tue Feb 13 16:11:35 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 16:11:37 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:24299 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039265AbXBMQLf (ORCPT ); Tue, 13 Feb 2007 16:11:35 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DGBZdY009660; Tue, 13 Feb 2007 16:11:35 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DGBY7d009659; Tue, 13 Feb 2007 16:11:34 GMT Date: Tue, 13 Feb 2007 16:11:34 +0000 From: Ralf Baechle To: Atsushi Nemoto Cc: vagabon.xyz@gmail.com, linux-mips@linux-mips.org Subject: Re: More __get_user_asm_ll32 ... Message-ID: <20070213161134.GB4942@linux-mips.org> References: <20070213133251.GA7518@linux-mips.org> <20070214.010615.101715999.anemo@mba.ocn.ne.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070214.010615.101715999.anemo@mba.ocn.ne.jp> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14075 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 14, 2007 at 01:06:15AM +0900, Atsushi Nemoto wrote: > Why is it clears the error return? The "3:" label is just after the > junk move. You're right and the final commit message reflects that. So this is really only a code size (320 bytes) and performance fix. Ralf From anemo@mba.ocn.ne.jp Tue Feb 13 16:13:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 16:13:28 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:36315 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039266AbXBMQNW (ORCPT ); Tue, 13 Feb 2007 16:13:22 +0000 Received: from localhost (p7211-ipad32funabasi.chiba.ocn.ne.jp [221.189.139.211]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id AA60AA3A8; Wed, 14 Feb 2007 01:12:02 +0900 (JST) Date: Wed, 14 Feb 2007 01:12:02 +0900 (JST) Message-Id: <20070214.011202.27778033.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, macro@linux-mips.org Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 From: Atsushi Nemoto In-Reply-To: <11713582901742-git-send-email-fbuihuu@gmail.com> References: <1171358289786-git-send-email-fbuihuu@gmail.com> <11713582901742-git-send-email-fbuihuu@gmail.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14076 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Tue, 13 Feb 2007 10:18:08 +0100, Franck Bui-Huu wrote: > + ifeq ("$(BUILD_ELF32)", "y") > + cflags-y += -msym32 ifeq ($(BUILD_ELF32),y) is enough, isn't it? --- Atsushi Nemoto From ralf@linux-mips.org Tue Feb 13 16:18:02 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 16:18:04 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:28362 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039278AbXBMQSC (ORCPT ); Tue, 13 Feb 2007 16:18:02 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DGI1Yh009951; Tue, 13 Feb 2007 16:18:01 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DGI101009950; Tue, 13 Feb 2007 16:18:01 GMT Date: Tue, 13 Feb 2007 16:18:01 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Message-ID: <20070213161801.GA9700@linux-mips.org> References: <1171358289786-git-send-email-fbuihuu@gmail.com> <11713582901742-git-send-email-fbuihuu@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <11713582901742-git-send-email-fbuihuu@gmail.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14077 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 13, 2007 at 10:18:08AM +0100, Franck Bui-Huu wrote: > + cflags-y += -DCONFIG_BUILD_ELF64 ^^^^^^^^^^^^^^^^^^^^ Preprocessor symbol names starting CONFIG_ are reserved for Kbuild. Ralf From vagabon.xyz@gmail.com Tue Feb 13 17:03:01 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 17:03:05 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.228]:20632 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039281AbXBMRDB (ORCPT ); Tue, 13 Feb 2007 17:03:01 +0000 Received: by qb-out-0506.google.com with SMTP id e12so787366qba for ; Tue, 13 Feb 2007 09:01:57 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=X0JJHqD9D6E5CKz1qCXIlREQSGnTT7Kij7mmv9pprDVEzmbfEIcTq85tCewSpoBseLm7oQIn3wLGth9hcxs9WGlSpEU0j/r8v6kvOi3xz3gfvv/Bp/wFnQs2rzOD/XQMRhgIuaIUGi/xtA3jqjk7cvMQ1bqbSE6G86uPk/vfJEE= Received: by 10.114.60.19 with SMTP id i19mr7910538waa.1171386116763; Tue, 13 Feb 2007 09:01:56 -0800 (PST) Received: by 10.114.136.11 with HTTP; Tue, 13 Feb 2007 09:01:56 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 18:01:56 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH] fix irq handling of DECstations Cc: "Atsushi Nemoto" , linux-mips@linux-mips.org In-Reply-To: <20070213152716.GA4942@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> <20070213022548.GB25323@linux-mips.org> <45D1C21A.9070801@innova-card.com> <20070213152716.GA4942@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14078 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/13/07, Ralf Baechle wrote: > On Tue, Feb 13, 2007 at 02:50:18PM +0100, Franck Bui-Huu wrote: > > > This patch makes these routines a lot more readable whatever > > the value of CONFIG_PREEMPT. > > Applied. argh there's a small mistake. Could you amend this fix ? -- >8 -- diff --git a/arch/mips/kernel/entry.S b/arch/mips/kernel/entry.S index c7429b2..0b78fcb 100644 --- a/arch/mips/kernel/entry.S +++ b/arch/mips/kernel/entry.S @@ -31,7 +31,7 @@ #ifndef CONFIG_PREEMPT FEXPORT(ret_from_exception) local_irq_disable # preempt stop - b _ret_from_irq + b __ret_from_irq #endif FEXPORT(ret_from_irq) LONG_S s0, TI_REGS($28) From vagabon.xyz@gmail.com Tue Feb 13 17:03:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 17:03:51 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.234]:10911 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039297AbXBMRDr (ORCPT ); Tue, 13 Feb 2007 17:03:47 +0000 Received: by qb-out-0506.google.com with SMTP id z8so950803qbc for ; Tue, 13 Feb 2007 09:02:46 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=gdDNRRR2KKwbke4AngDaAcFvb/+ji3Yrnr1OohitNdjBjd9ebJCfZYkiMTu0M2S+EMSRzIPdWZH0rgsn9T1fVc5Nh3J74JBLcY1y1SUhep0VwHOSfH0dVSsOi3v9+ZsYzKQrJ5m9I2KpWZwFEVwSBHCULCrd7XUW1KRjRkMbWxs= Received: by 10.114.202.15 with SMTP id z15mr7885059waf.1171386166175; Tue, 13 Feb 2007 09:02:46 -0800 (PST) Received: by 10.114.136.11 with HTTP; Tue, 13 Feb 2007 09:02:46 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 18:02:46 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, macro@linux-mips.org In-Reply-To: <20070214.011202.27778033.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1171358289786-git-send-email-fbuihuu@gmail.com> <11713582901742-git-send-email-fbuihuu@gmail.com> <20070214.011202.27778033.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14079 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/13/07, Atsushi Nemoto wrote: > On Tue, 13 Feb 2007 10:18:08 +0100, Franck Bui-Huu wrote: > > + ifeq ("$(BUILD_ELF32)", "y") > > + cflags-y += -msym32 > > ifeq ($(BUILD_ELF32),y) > > is enough, isn't it? yes it is, I'll change it. thanks -- Franck From vagabon.xyz@gmail.com Tue Feb 13 17:10:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 17:10:39 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.228]:52150 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038483AbXBMRKe (ORCPT ); Tue, 13 Feb 2007 17:10:34 +0000 Received: by qb-out-0506.google.com with SMTP id e12so788230qba for ; Tue, 13 Feb 2007 09:09:33 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=YQTs4VhWP/xfYwxfG+safdxqoprLogHvwHTuk/exRgYGRlAzVbJnv6QSOev16Nma8qiRdnHUTHFicdAUg1Q1A+ToCDeznVDuxwBcsHw6nkUnmyemhfVVgkLsZxuoDIbEcHFVzxyHV/d02m3gcaGB4qx1tp5w2NUJ0LyB4dV/uJI= Received: by 10.114.152.17 with SMTP id z17mr7920896wad.1171386572964; Tue, 13 Feb 2007 09:09:32 -0800 (PST) Received: by 10.114.136.11 with HTTP; Tue, 13 Feb 2007 09:09:32 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 18:09:32 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org In-Reply-To: <20070213161801.GA9700@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1171358289786-git-send-email-fbuihuu@gmail.com> <11713582901742-git-send-email-fbuihuu@gmail.com> <20070213161801.GA9700@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14080 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/13/07, Ralf Baechle wrote: > On Tue, Feb 13, 2007 at 10:18:08AM +0100, Franck Bui-Huu wrote: > > > + cflags-y += -DCONFIG_BUILD_ELF64 > ^^^^^^^^^^^^^^^^^^^^ > > Preprocessor symbol names starting CONFIG_ are reserved for Kbuild. > Ok but keeping this name avoid to change all places where CONFIG_BUILD_ELF64 is used. It should be done by patch #3 instead where CONFIG_BUILD_ELF64 is renamed into CONFIG_64BIT_BUILD_ELF32. Any suggestions for a better name ? -- Franck From vagabon.xyz@gmail.com Tue Feb 13 17:18:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 17:18:36 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.235]:36308 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038861AbXBMRSc (ORCPT ); Tue, 13 Feb 2007 17:18:32 +0000 Received: by qb-out-0506.google.com with SMTP id e12so789079qba for ; Tue, 13 Feb 2007 09:17:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=iSADV7FD1cRYlSwZhpcxSFwW4iV5i/V+qtu5iiYMChHKEJsO70bIc/gyxA7NrPB05hsIhSozgYSGCJuT6M5D7mPHIwXTxUKN0Y64AgZiA1iCnKQFC380JfZIlw0M38ndupsL82XpNOV9VsakQ0aC3viNxVP+twscOFPI0yJjhxY= Received: by 10.114.211.1 with SMTP id j1mr6879450wag.1171387045157; Tue, 13 Feb 2007 09:17:25 -0800 (PST) Received: by 10.114.136.11 with HTTP; Tue, 13 Feb 2007 09:17:25 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 18:17:25 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH 3/3] signal.c: fix gcc warning on 32 bits kernel Cc: "Atsushi Nemoto" , linux-mips@linux-mips.org In-Reply-To: <20070213020556.GA5875@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070209210014.GA26939@linux-mips.org> <20070212140459.GA9679@linux-mips.org> <20070213.002545.03977174.anemo@mba.ocn.ne.jp> <20070213014345.GA30988@linux-mips.org> <20070213020556.GA5875@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14081 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/13/07, Ralf Baechle wrote: > On Tue, Feb 13, 2007 at 01:43:45AM +0000, Ralf Baechle wrote: > > > Well, I reverted that the old state of a warning is definately preferable > > until we found a proper solution. > > Type-punning should do the trick. > yes it does. thanks. -- Franck From ralf@linux-mips.org Tue Feb 13 17:22:34 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 17:22:35 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:48342 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039030AbXBMRWe (ORCPT ); Tue, 13 Feb 2007 17:22:34 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1DHMX9E022833; Tue, 13 Feb 2007 17:22:33 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1DHMWEh022830; Tue, 13 Feb 2007 17:22:32 GMT Date: Tue, 13 Feb 2007 17:22:32 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: Atsushi Nemoto , linux-mips@linux-mips.org Subject: Re: [PATCH] fix irq handling of DECstations Message-ID: <20070213172232.GA22447@linux-mips.org> References: <20070212.234826.59032634.anemo@mba.ocn.ne.jp> <20070213022548.GB25323@linux-mips.org> <45D1C21A.9070801@innova-card.com> <20070213152716.GA4942@linux-mips.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14082 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Tue, Feb 13, 2007 at 06:01:56PM +0100, Franck Bui-Huu wrote: > argh there's a small mistake. Could you amend this fix ? Fortunately I haven't pushed yet, so yes, will do git surgery :) Ralf From djohnson@sw.starentnetworks.com Tue Feb 13 19:04:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 19:04:17 +0000 (GMT) Received: from newmail.sw.starentnetworks.com ([12.33.234.78]:657 "EHLO mail.sw.starentnetworks.com") by ftp.linux-mips.org with ESMTP id S20039277AbXBMTEM (ORCPT ); Tue, 13 Feb 2007 19:04:12 +0000 Received: from zeus.sw.starentnetworks.com (zeus.sw.starentnetworks.com [12.33.233.46]) by mail.sw.starentnetworks.com (Postfix) with ESMTP id 26C1D3ED7F; Tue, 13 Feb 2007 14:03:31 -0500 (EST) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <17874.2946.982942.958962@zeus.sw.starentnetworks.com> Date: Tue, 13 Feb 2007 14:03:30 -0500 From: Dave Johnson To: Atsushi Nemoto Cc: linux-mips@linux-mips.org Subject: Re: problems booting sb1250, page fault issue? In-Reply-To: <20070213.233505.64804701.anemo@mba.ocn.ne.jp> References: <17869.2075.900049.547334@zeus.sw.starentnetworks.com> <20070211.010336.15248113.anemo@mba.ocn.ne.jp> <17872.61204.190437.109367@zeus.sw.starentnetworks.com> <20070213.233505.64804701.anemo@mba.ocn.ne.jp> X-Mailer: VM 7.17 under 21.4 (patch 17) "Jumbo Shrimp" XEmacs Lucid Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14083 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: djohnson+linux-mips@sw.starentnetworks.com Precedence: bulk X-list: linux-mips Atsushi Nemoto writes: > On Mon, 12 Feb 2007 17:49:56 -0500, Dave Johnson wrote: > > I added both flush_data_cache_page to c-sb1.c and > > __flush_icache_page() to flush_icache_page in cacheflush.h. > > > > With those, the page faults work correctly and booting seems to be > > reliable on 2.6.18. > > I think the problem of c-sb1.c was fixed in lmo 2.6.18-stable branch. > Could you try it? I merged in the flush_data_cache_page routine (from linux-2.6.18.6 tag) instead of the ones from the mailing list and it's good as well. Even though local_flush_data_cache_page is only used in __ide_flush_dcache_range() (and that is inside a cpu_has_dc_aliases check) it still might be good to fill it out anyway. -- Dave Johnson Starent Networks From vagabon.xyz@gmail.com Tue Feb 13 20:06:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 20:06:16 +0000 (GMT) Received: from nz-out-0506.google.com ([64.233.162.227]:17995 "EHLO nz-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20039293AbXBMUGM (ORCPT ); Tue, 13 Feb 2007 20:06:12 +0000 Received: by nz-out-0506.google.com with SMTP id x7so2139662nzc for ; Tue, 13 Feb 2007 12:05:07 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=BqAUcNgq2NO2wJVqL8/IhAuLdnsZzvFWvChJAd5JafkQwU1MI1EWuhgJO2aDxToKAh5BoxoOxbpfgY9ag2Cn97C5OsywzENpGSnbhP9DDvoHG9HU9XzAYU+kzB/WDaMPJxtk8cw6EvHfqRP8bhXzb1S+C9nvKj+IIlnkGA5mOG8= Received: by 10.114.161.11 with SMTP id j11mr8150370wae.1171397106616; Tue, 13 Feb 2007 12:05:06 -0800 (PST) Received: by 10.114.136.11 with HTTP; Tue, 13 Feb 2007 12:05:06 -0800 (PST) Message-ID: Date: Tue, 13 Feb 2007 21:05:06 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Cc: linux-mips@linux-mips.org, anemo@mba.ocn.ne.jp, macro@linux-mips.org In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <1171358289786-git-send-email-fbuihuu@gmail.com> <11713582901742-git-send-email-fbuihuu@gmail.com> <20070213161801.GA9700@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14084 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/13/07, Franck Bui-Huu wrote: > On 2/13/07, Ralf Baechle wrote: > > On Tue, Feb 13, 2007 at 10:18:08AM +0100, Franck Bui-Huu wrote: > > > > > + cflags-y += -DCONFIG_BUILD_ELF64 > > ^^^^^^^^^^^^^^^^^^^^ > > > > Preprocessor symbol names starting CONFIG_ are reserved for Kbuild. > > > > Ok but keeping this name avoid to change all places where > CONFIG_BUILD_ELF64 is used. > > It should be done by patch #3 instead where CONFIG_BUILD_ELF64 is > renamed into CONFIG_64BIT_BUILD_ELF32. Any suggestions for a better > name ? What about KBUILD_64BIT_ELF32 with 'KBUILD' meaning that it comes from Kbuild itself and not from any Kconfig files ? -- Franck From Marc_St-Jean@pmc-sierra.com Tue Feb 13 22:13:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Tue, 13 Feb 2007 22:13:16 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:51697 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039006AbXBMWNL (ORCPT ); Tue, 13 Feb 2007 22:13:11 +0000 Received: (qmail 6404 invoked by uid 101); 13 Feb 2007 22:11:21 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by mother.pmc-sierra.com with SMTP; 13 Feb 2007 22:11:21 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1DMBKWp027771; Tue, 13 Feb 2007 14:11:20 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <1CC7YAJL>; Tue, 13 Feb 2007 14:11:20 -0800 Message-ID: <45D23785.6060502@pmc-sierra.com> From: Marc St-Jean To: Andrew Morton Cc: linux-kernel@vger.kernel.org, linux-serial@vger.kernel.org, linux-mips@linux-mips.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Tue, 13 Feb 2007 14:11:17 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 13 Feb 2007 22:11:18.0467 (UTC) FILETIME=[E2BA0930:01C74FBB] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14085 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Andrew Morton wrote: > On Mon, 12 Feb 2007 12:04:08 -0600 Marc St-Jean > wrote: > > > There are three different fixes: > > 1. Fix for DesignWare THRE errata > > - Dropped our fix since the "8250-uart-backup-timer.patch" in the "mm" > > tree also fixes it. This patch needs to be applied on top of "mm" patch. > > > > 2. Fix for Busy Detect on LCR write > > - No changes since last patch. > > > > 3. Workaround for interrupt/data concurrency issue > > - No changes since last patch. > > A couple of things. > > - When preparing a changelog, please just tell us what the patch does. > The information about how this patch differes from a previous version of > the patch is irrelevant when the patch hits the mainline repository hence > I must edit it all. > > It's OK to add the what-i-changed-since-last-time details, but please > make > that separate and remember that it will be removed for when the patch > goes > upstream. > > - When fixing a bug, please tell us in detail what that bug *is*. None > of the above three items tell us any of this, which is essential > information for those who are to review the change. Understood, I'm adding the original description here and I'll add to the next patch update. 1. Fix for DesignWare APB THRE errata: In brief, this is a non-standard 16550 in that the THRE interrupt will not re-assert itself simply by disabling and re-enabling the THRI bit in the IER, it is only re-enabled if a character is actually sent out. It appears that the "8250-uart-backup-timer.patch" in the "mm" tree also fixes it so we have dropped our initial workaround. This patch now needs to be applied on top of that "mm" patch. 2. Fix for Busy Detect on LCR write: The DesignWare APB UART has a feature which causes a new Busy Detect interrupt to be generated if it's busy when the LCR is written. This fix saves the value of the LCR and rewrites it after clearing the interrupt. 3. Workaround for interrupt/data concurrency issue: The SoC needs to ensure that writes that can cause interrupts to be cleared reach the UART before returning from the ISR. This fix reads a non-destructive register on the UART so the read transaction completion ensures the previously queued write transaction has also completed. > > > > + case UPIO_DWAPB: > > + /* Save the LCR value so it can be re-written when a > > + * Busy Detect interrupt occurs. */ > > + if (save_offset == UART_LCR) > > + up->lcr = value; > > + writeb(value, up->port.membase + offset); > > + /* Read the IER to ensure any interrupt is cleared before > > + * returning from ISR. */ > > + if ((save_offset == UART_TX || save_offset == UART_IER) > && in_irq()) > > The in_irq() is a worry. If the serial driver is used as the system > console, then it can be called from _any_ interrupt handler. eg a printk() > in the sata code. > > What happens then? The in_irq() is there to improve performance. The logic being that writing to registers outside the interrupt context will not require the fix for issue 3. There should be no issues if called from other interrupt context as the read is non-destructive. I can remove the call to in_irq() if you prefer. > > @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( > > handled = 1; > > > > end = NULL; > > + } else if (up->port.iotype == UPIO_DWAPB && > > + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { > > + /* The DesignWare APB UART has an Busy Detect > (0x07) > > + * interrupt meaning an LCR write attempt > occured while the > > + * UART was busy. The interrupt must be cleared > by reading > > + * the UART status register (USR) and the LCR > re-written. */ > > + unsigned int status; > > + status = *(volatile u32 *)up->port.private_data; > > Are you sure this is right? The use of volatile is generally discouraged > and is a sign that something is wrong. What is the driver attempting to > read here? Should it be using readl()? The driver is reading the UART's USR (UART Status Register) which is a non-standard register at a non-fixed offset, hence the need for private_data. This was discussed in detail in the patch thread and the goal was to avoid using platform specific #ifdefs as part of the fix The register is accessed in kseg1 (unmapped on the mips architecture) so readl is not needed. The register definitions in this space are all marked volatile but since it's now accessed through private_data, the read had to be made explicitly volatile. > Also, the newly-added private_data field is not being initialised to > anything anywhere in this patch. private_data is initialized in the platform specific initialization code which will be submitted to the l-m.o That patch contains only code which lives in arch/mips and include/asm-mips so I was not planning on submitting to the main kernel list. This level of procedural detail is not in the maillist FAQ, I'm assuming that is normal procedure? Marc From anemo@mba.ocn.ne.jp Wed Feb 14 01:28:29 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 01:28:34 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:28511 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20039457AbXBNB23 (ORCPT ); Wed, 14 Feb 2007 01:28:29 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 14 Feb 2007 10:28:26 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 511D241EA4; Wed, 14 Feb 2007 10:28:02 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id 4463F20608; Wed, 14 Feb 2007 10:28:02 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l1E1S1W0093759; Wed, 14 Feb 2007 10:28:01 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 14 Feb 2007 10:28:01 +0900 (JST) Message-Id: <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, macro@linux-mips.org Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 From: Atsushi Nemoto In-Reply-To: References: <11713582901742-git-send-email-fbuihuu@gmail.com> <20070213161801.GA9700@linux-mips.org> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14086 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Tue, 13 Feb 2007 18:09:32 +0100, "Franck Bui-Huu" wrote: > It should be done by patch #3 instead where CONFIG_BUILD_ELF64 is > renamed into CONFIG_64BIT_BUILD_ELF32. Any suggestions for a better > name ? I think "ELF32" or "ELF64" word is improper while this is irrelevant to ELF format. This makes confusion with CONFIG_BOOT_ELF32. How about simple BUILD_SYM32? And replase BUILD_ELF32 with BUILD_SYM32 too? --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Feb 14 08:04:59 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 08:05:03 +0000 (GMT) Received: from topsns2.toshiba-tops.co.jp ([202.230.225.126]:48477 "EHLO topsns2.toshiba-tops.co.jp") by ftp.linux-mips.org with ESMTP id S20027656AbXBNIE7 (ORCPT ); Wed, 14 Feb 2007 08:04:59 +0000 Received: from topsms.toshiba-tops.co.jp by topsns2.toshiba-tops.co.jp via smtpd (for ftp.linux-mips.org [194.74.144.162]) with ESMTP; Wed, 14 Feb 2007 17:04:54 +0900 Received: from topsms.toshiba-tops.co.jp (localhost.localdomain [127.0.0.1]) by localhost.toshiba-tops.co.jp (Postfix) with ESMTP id 104AF42056; Wed, 14 Feb 2007 17:04:22 +0900 (JST) Received: from srd2sd.toshiba-tops.co.jp (srd2sd.toshiba-tops.co.jp [172.17.28.2]) by topsms.toshiba-tops.co.jp (Postfix) with ESMTP id F078E41C73; Wed, 14 Feb 2007 17:04:21 +0900 (JST) Received: from localhost (fragile [172.17.28.65]) by srd2sd.toshiba-tops.co.jp (8.12.10/8.12.10) with ESMTP id l1E84LW0095097; Wed, 14 Feb 2007 17:04:21 +0900 (JST) (envelope-from anemo@mba.ocn.ne.jp) Date: Wed, 14 Feb 2007 17:04:20 +0900 (JST) Message-Id: <20070214.170420.85684996.nemoto@toshiba-tops.co.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: <20070209.130316.14978798.nemoto@toshiba-tops.co.jp> References: <20070209.015405.08319291.anemo@mba.ocn.ne.jp> <20070209.130316.14978798.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.3 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14087 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips Revised again. Fix check_and_restore_fp_context32 and rediff against current git. Subject: Check FCSR for pending interrupts, alternative version The commit 6d6671066a311703bca1b91645bb1e04cc983387 is incomplete and misses non-r4k CPUs. This patch reverts the commit and fixes in other way. * Do FCSR checking in caller of restore_fp_context. * Send SIGFPE if the signal handler set any FPU exception bits. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/r4k_fpu.S | 16 ------------ arch/mips/kernel/signal-common.h | 3 ++ arch/mips/kernel/signal.c | 46 ++++++++++++++++++++++++++++++++++--- arch/mips/kernel/signal32.c | 27 +++++++++++++++++++-- arch/mips/kernel/signal_n32.c | 6 ++++ 5 files changed, 75 insertions(+), 23 deletions(-) diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S index 59c1577..dbd42ad 100644 --- a/arch/mips/kernel/r4k_fpu.S +++ b/arch/mips/kernel/r4k_fpu.S @@ -114,14 +114,6 @@ LEAF(_save_fp_context32) */ LEAF(_restore_fp_context) EX lw t0, SC_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - #ifdef CONFIG_64BIT EX ldc1 $f1, SC_FPREGS+8(a0) EX ldc1 $f3, SC_FPREGS+24(a0) @@ -165,14 +157,6 @@ LEAF(_restore_fp_context) LEAF(_restore_fp_context32) /* Restore an o32 sigcontext. */ EX lw t0, SC32_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - EX ldc1 $f0, SC32_FPREGS+0(a0) EX ldc1 $f2, SC32_FPREGS+16(a0) EX ldc1 $f4, SC32_FPREGS+32(a0) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index fdbdbdc..297dfcb 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -31,4 +31,7 @@ extern void __user *get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, */ extern int install_sigtramp(unsigned int __user *tramp, unsigned int syscall); +/* Check and clear pending FPU exceptions in saved CSR */ +extern int fpcsr_pending(unsigned int __user *fpcsr); + #endif /* __SIGNAL_COMMON_H */ diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index b2e9ab1..2420ed6 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -121,6 +121,37 @@ int setup_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) return err; } +int fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static int +check_and_restore_fp_context(struct sigcontext __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context(sc); + return err ?: sig; +} + int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { unsigned int used_math; @@ -155,7 +186,8 @@ int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context(sc); + if (!err) + err = check_and_restore_fp_context(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -325,6 +357,7 @@ asmlinkage void sys_sigreturn(nabi_no_regargs struct pt_regs regs) { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -338,8 +371,11 @@ asmlinkage void sys_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->sf_sc)) + sig = restore_sigcontext(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -361,6 +397,7 @@ asmlinkage void sys_rt_sigreturn(nabi_no_regargs struct pt_regs regs) struct rt_sigframe __user *frame; sigset_t set; stack_t st; + int sig; frame = (struct rt_sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -374,8 +411,11 @@ asmlinkage void sys_rt_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); if (__copy_from_user(&st, &frame->rs_uc.uc_stack, sizeof(st))) goto badframe; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index dd4e518..813279d 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -220,6 +220,18 @@ static int setup_sigcontext32(struct pt_regs *regs, return err; } +static int +check_and_restore_fp_context32(struct sigcontext32 __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context32(sc); + return err ?: sig; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) { @@ -255,7 +267,8 @@ static int restore_sigcontext32(struct pt_regs *regs, if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context32(sc); + if (!err) + err = check_and_restore_fp_context32(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -508,6 +521,7 @@ asmlinkage void sys32_sigreturn(nabi_no_regargs struct pt_regs regs) { struct sigframe32 __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -521,8 +535,11 @@ asmlinkage void sys32_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->sf_sc)) + sig = restore_sigcontext32(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -545,6 +562,7 @@ asmlinkage void sys32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) sigset_t set; stack_t st; s32 sp; + int sig; frame = (struct rt_sigframe32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -558,8 +576,11 @@ asmlinkage void sys32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext32(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* The ucontext contains a stack32_t, so we must convert! */ if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp)) diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index 7ca2a07..26ca944 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -126,6 +126,7 @@ asmlinkage void sysn32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) sigset_t set; stack_t st; s32 sp; + int sig; frame = (struct rt_sigframe_n32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -139,8 +140,11 @@ asmlinkage void sysn32_rt_sigreturn(nabi_no_regargs struct pt_regs regs) recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* The ucontext contains a stack32_t, so we must convert! */ if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp)) From vagabon.xyz@gmail.com Wed Feb 14 08:21:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 08:21:31 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.224]:16133 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20027704AbXBNIV1 (ORCPT ); Wed, 14 Feb 2007 08:21:27 +0000 Received: by qb-out-0506.google.com with SMTP id e12so8404qba for ; Wed, 14 Feb 2007 00:20:23 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=LjuOVenIWI9/X8r9nQmmnKtWmKzksdqGwlWWm3AjMp2ror15atUvzojlPzjjQOa57spN9MLZfJ8OXLJv5O0S/st4GOZ/OD9HcAJK+pqAPSZ4ZEYcddcu8DEx5kbzzqlpz1hq4JMmdoMErypxEA28mxqJ6rpuZnV5MLgfvo+9kSg= Received: by 10.114.157.1 with SMTP id f1mr7050wae.1171441222699; Wed, 14 Feb 2007 00:20:22 -0800 (PST) Received: by 10.114.136.11 with HTTP; Wed, 14 Feb 2007 00:20:22 -0800 (PST) Message-ID: Date: Wed, 14 Feb 2007 09:20:22 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, macro@linux-mips.org In-Reply-To: <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11713582901742-git-send-email-fbuihuu@gmail.com> <20070213161801.GA9700@linux-mips.org> <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14088 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/14/07, Atsushi Nemoto wrote: > On Tue, 13 Feb 2007 18:09:32 +0100, "Franck Bui-Huu" wrote: > > It should be done by patch #3 instead where CONFIG_BUILD_ELF64 is > > renamed into CONFIG_64BIT_BUILD_ELF32. Any suggestions for a better > > name ? > > I think "ELF32" or "ELF64" word is improper while this is irrelevant > to ELF format. This makes confusion with CONFIG_BOOT_ELF32. > > How about simple BUILD_SYM32? And replase BUILD_ELF32 with > BUILD_SYM32 too? > That's a good point. What about replacing BUILD by KBUILD meaning this macro is coming from Kbuild itsel ? And maybe it would be interesting to make obvious that this macro implies 64-bits kernel. What about something like KBUILD_64BIT_SYM32 and replace 'BUILD_ELF32=no' by 'KBUILD_SYM32=no' ? -- Franck From vagabon.xyz@gmail.com Wed Feb 14 08:35:55 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 08:35:59 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.231]:24360 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037435AbXBNIfz (ORCPT ); Wed, 14 Feb 2007 08:35:55 +0000 Received: by qb-out-0506.google.com with SMTP id e12so10156qba for ; Wed, 14 Feb 2007 00:34:54 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=J0rXuPp41phMBkm37emp7+DJf7yLVbJ9M5VSXpZbtq/Ql2ZCzJkFC/BGmzX0hNLlQgS0JneXYVQA0K6d2XV9+KaahwMbfr/rsLY3CC9ETjVuURAW1b2vNTJypVsctKlh29N5+pinOlTAabLb50nQA+kHTc+ztQxoQQJLN8e0wf8= Received: by 10.114.132.5 with SMTP id f5mr6472wad.1171442093579; Wed, 14 Feb 2007 00:34:53 -0800 (PST) Received: by 10.114.136.11 with HTTP; Wed, 14 Feb 2007 00:34:53 -0800 (PST) Message-ID: Date: Wed, 14 Feb 2007 09:34:53 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org In-Reply-To: <20070214.170420.85684996.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070209.015405.08319291.anemo@mba.ocn.ne.jp> <20070209.130316.14978798.nemoto@toshiba-tops.co.jp> <20070214.170420.85684996.nemoto@toshiba-tops.co.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14089 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips Hi Atsushi, On 2/14/07, Atsushi Nemoto wrote: > Revised again. Fix check_and_restore_fp_context32 and rediff against > current git. > > > Subject: Check FCSR for pending interrupts, alternative version > [snip] > diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h > index fdbdbdc..297dfcb 100644 > --- a/arch/mips/kernel/signal-common.h > +++ b/arch/mips/kernel/signal-common.h > @@ -31,4 +31,7 @@ extern void __user *get_sigframe(struct k_sigaction *ka, struct pt_regs *regs, > */ > extern int install_sigtramp(unsigned int __user *tramp, unsigned int syscall); > > +/* Check and clear pending FPU exceptions in saved CSR */ > +extern int fpcsr_pending(unsigned int __user *fpcsr); > + Just my 2 cents: This looks like the wrong place for this fpu prototype. I mean shouldn't it belong to a fpu header file or something else ? -- Franck From macro@linux-mips.org Wed Feb 14 11:42:54 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 11:42:59 +0000 (GMT) Received: from pollux.ds.pg.gda.pl ([153.19.208.7]:35333 "EHLO pollux.ds.pg.gda.pl") by ftp.linux-mips.org with ESMTP id S20037594AbXBNLmy (ORCPT ); Wed, 14 Feb 2007 11:42:54 +0000 Received: from localhost (localhost [127.0.0.1]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id 27A2FE1CAA; Wed, 14 Feb 2007 12:42:15 +0100 (CET) X-Virus-Scanned: by amavisd-new at pollux.ds.pg.gda.pl Received: from pollux.ds.pg.gda.pl ([127.0.0.1]) by localhost (pollux.ds.pg.gda.pl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KdZbWgbpgpYw; Wed, 14 Feb 2007 12:42:14 +0100 (CET) Received: from piorun.ds.pg.gda.pl (piorun.ds.pg.gda.pl [153.19.208.8]) by pollux.ds.pg.gda.pl (Postfix) with ESMTP id C6E12E1C61; Wed, 14 Feb 2007 12:42:14 +0100 (CET) Received: from blysk.ds.pg.gda.pl (macro@blysk.ds.pg.gda.pl [153.19.208.6]) by piorun.ds.pg.gda.pl (8.13.8/8.13.8) with ESMTP id l1EBgMjc016131; Wed, 14 Feb 2007 12:42:23 +0100 Date: Wed, 14 Feb 2007 11:42:19 +0000 (GMT) From: "Maciej W. Rozycki" To: Atsushi Nemoto cc: vagabon.xyz@gmail.com, ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 In-Reply-To: <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> Message-ID: References: <11713582901742-git-send-email-fbuihuu@gmail.com> <20070213161801.GA9700@linux-mips.org> <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Virus-Scanned: ClamAV 0.88.7/2565/Wed Feb 14 08:36:47 2007 on piorun.ds.pg.gda.pl X-Virus-Status: Clean Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14090 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: macro@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, 14 Feb 2007, Atsushi Nemoto wrote: > How about simple BUILD_SYM32? And replase BUILD_ELF32 with > BUILD_SYM32 too? It sounds reasonable to me. Maciej From anemo@mba.ocn.ne.jp Wed Feb 14 16:06:52 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 16:06:54 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:62939 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038462AbXBNQGw (ORCPT ); Wed, 14 Feb 2007 16:06:52 +0000 Received: from localhost (p1218-ipad205funabasi.chiba.ocn.ne.jp [222.146.96.218]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 66626BAEC; Thu, 15 Feb 2007 01:05:31 +0900 (JST) Date: Thu, 15 Feb 2007 01:05:31 +0900 (JST) Message-Id: <20070215.010531.79072528.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: References: <20070209.130316.14978798.nemoto@toshiba-tops.co.jp> <20070214.170420.85684996.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14091 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 14 Feb 2007 09:34:53 +0100, "Franck Bui-Huu" wrote: > > +/* Check and clear pending FPU exceptions in saved CSR */ > > +extern int fpcsr_pending(unsigned int __user *fpcsr); > > + > > Just my 2 cents: This looks like the wrong place for this fpu > prototype. I mean shouldn't it belong to a fpu header file or > something else ? Well, this is a helper function for signal so signal-common.h is not so bad, I think. And adding to kernel/signal-common.h looks less intrusive than adding to include/asm-mips/fpu.h, in my impression. --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Wed Feb 14 16:15:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 16:15:43 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:44258 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038726AbXBNQPm (ORCPT ); Wed, 14 Feb 2007 16:15:42 +0000 Received: from localhost (p1218-ipad205funabasi.chiba.ocn.ne.jp [222.146.96.218]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id B3BCE9164; Thu, 15 Feb 2007 01:14:20 +0900 (JST) Date: Thu, 15 Feb 2007 01:14:20 +0900 (JST) Message-Id: <20070215.011420.15247947.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, macro@linux-mips.org Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 From: Atsushi Nemoto In-Reply-To: References: <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14092 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 14 Feb 2007 09:20:22 +0100, "Franck Bui-Huu" wrote: > That's a good point. What about replacing BUILD by KBUILD meaning this > macro is coming from Kbuild itsel ? No objections. > And maybe it would be interesting to make obvious that this macro > implies 64-bits kernel. What about something like KBUILD_64BIT_SYM32 > and replace 'BUILD_ELF32=no' by 'KBUILD_SYM32=no' ? Same here. I just think introducing one name is better than two name. I also feel "make KBUILD_SYM32=0" is more consistent. --- Atsushi Nemoto From ralf@linux-mips.org Wed Feb 14 21:42:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Wed, 14 Feb 2007 21:42:29 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:55021 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039581AbXBNVm1 (ORCPT ); Wed, 14 Feb 2007 21:42:27 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1ELgRig008291; Wed, 14 Feb 2007 21:42:28 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1ELgQpO008290; Wed, 14 Feb 2007 21:42:26 GMT Date: Wed, 14 Feb 2007 21:42:26 +0000 From: Ralf Baechle To: Andrew Morton Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-ID: <20070214214226.GA17899@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20060306170552.0aab29c5.akpm@osdl.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14093 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips Time for a little bit of dead horse flogging. On Mon, Mar 06, 2006 at 05:05:52PM -0800, Andrew Morton wrote: > > --- a/include/asm-generic/unaligned.h > > +++ b/include/asm-generic/unaligned.h > > @@ -78,7 +78,7 @@ static inline void __ustw(__u16 val, __u > > > > #define __get_unaligned(ptr, size) ({ \ > > const void *__gu_p = ptr; \ > > - __typeof__(*(ptr)) val; \ > > + __u64 val; \ > > switch (size) { \ > > case 1: \ > > val = *(const __u8 *)__gu_p; \ > > @@ -95,7 +95,7 @@ static inline void __ustw(__u16 val, __u > > default: \ > > bad_unaligned_access_length(); \ > > }; \ > > - val; \ > > + (__typeof__(*(ptr)))val; \ > > }) > > > > #define __put_unaligned(val, ptr, size) \ > > I worry about what impact that change might have on code generation. > Hopefully none, if gcc is good enough. > > But I cannot think of a better fix. It does inflate the code but back then we agreed to go for Atsushi's patch because it was fairly obviously correct. This patch obviously is less obvious but generates fairly decent, works for arbitrary data types and cuts down the size of unaligned.h from 122 lines to 44 so it must be good. Ralf Signed-off-by: Ralf Baechle diff --git a/include/asm-generic/unaligned.h b/include/asm-generic/unaligned.h index 09ec447..d7fda33 100644 --- a/include/asm-generic/unaligned.h +++ b/include/asm-generic/unaligned.h @@ -1,122 +1,44 @@ -#ifndef _ASM_GENERIC_UNALIGNED_H_ -#define _ASM_GENERIC_UNALIGNED_H_ - /* - * For the benefit of those who are trying to port Linux to another - * architecture, here are some C-language equivalents. + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. * - * This is based almost entirely upon Richard Henderson's - * asm-alpha/unaligned.h implementation. Some comments were - * taken from David Mosberger's asm-ia64/unaligned.h header. + * Copyright (C) 2006 MIPS Technologies, Inc. + * written by Ralf Baechle */ +#ifndef __ASM_GENERIC_UNALIGNED_H +#define __ASM_GENERIC_UNALIGNED_H #include -/* - * The main single-value unaligned transfer routines. - */ -#define get_unaligned(ptr) \ - __get_unaligned((ptr), sizeof(*(ptr))) -#define put_unaligned(x,ptr) \ - __put_unaligned((__u64)(x), (ptr), sizeof(*(ptr))) - -/* - * This function doesn't actually exist. The idea is that when - * someone uses the macros below with an unsupported size (datatype), - * the linker will alert us to the problem via an unresolved reference - * error. - */ -extern void bad_unaligned_access_length(void) __attribute__((noreturn)); - -struct __una_u64 { __u64 x __attribute__((packed)); }; -struct __una_u32 { __u32 x __attribute__((packed)); }; -struct __una_u16 { __u16 x __attribute__((packed)); }; - -/* - * Elemental unaligned loads - */ - -static inline __u64 __uldq(const __u64 *addr) -{ - const struct __una_u64 *ptr = (const struct __una_u64 *) addr; - return ptr->x; -} - -static inline __u32 __uldl(const __u32 *addr) -{ - const struct __una_u32 *ptr = (const struct __una_u32 *) addr; - return ptr->x; -} - -static inline __u16 __uldw(const __u16 *addr) -{ - const struct __una_u16 *ptr = (const struct __una_u16 *) addr; - return ptr->x; -} - /* - * Elemental unaligned stores + * The unused member __un_foo is there to suppress "warning: ´packed´ + * attribute ignored for field of type ´union ´" messages if + * ptr is char *. */ -static inline void __ustq(__u64 val, __u64 *addr) -{ - struct __una_u64 *ptr = (struct __una_u64 *) addr; - ptr->x = val; -} - -static inline void __ustl(__u32 val, __u32 *addr) -{ - struct __una_u32 *ptr = (struct __una_u32 *) addr; - ptr->x = val; -} - -static inline void __ustw(__u16 val, __u16 *addr) -{ - struct __una_u16 *ptr = (struct __una_u16 *) addr; - ptr->x = val; -} - -#define __get_unaligned(ptr, size) ({ \ - const void *__gu_p = ptr; \ - __u64 val; \ - switch (size) { \ - case 1: \ - val = *(const __u8 *)__gu_p; \ - break; \ - case 2: \ - val = __uldw(__gu_p); \ - break; \ - case 4: \ - val = __uldl(__gu_p); \ - break; \ - case 8: \ - val = __uldq(__gu_p); \ - break; \ - default: \ - bad_unaligned_access_length(); \ - }; \ - (__typeof__(*(ptr)))val; \ +#define get_unaligned(ptr) \ +({ \ + const struct { \ + union { \ + const int __un_foo[0]; \ + const __typeof__(*(ptr)) __un; \ + } __un __attribute__ ((packed)); \ + } * const __gu_p = (void *) (ptr); \ + \ + __gu_p->__un.__un; \ }) -#define __put_unaligned(val, ptr, size) \ -do { \ - void *__gu_p = ptr; \ - switch (size) { \ - case 1: \ - *(__u8 *)__gu_p = val; \ - break; \ - case 2: \ - __ustw(val, __gu_p); \ - break; \ - case 4: \ - __ustl(val, __gu_p); \ - break; \ - case 8: \ - __ustq(val, __gu_p); \ - break; \ - default: \ - bad_unaligned_access_length(); \ - }; \ +#define put_unaligned(val, ptr) \ +do { \ + struct { \ + union { \ + const int __un_foo[0]; \ + __typeof__(*(ptr)) __un; \ + } __un __attribute__ ((packed)); \ + } * const __gu_p = (void *) (ptr); \ + \ + __gu_p->__un.__un = (val); \ } while(0) -#endif /* _ASM_GENERIC_UNALIGNED_H */ +#endif /* __ASM_GENERIC_UNALIGNED_H */ From barrioskmc@gmail.com Thu Feb 15 01:47:46 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 01:47:51 +0000 (GMT) Received: from py-out-1112.google.com ([64.233.166.177]:58980 "EHLO py-out-1112.google.com") by ftp.linux-mips.org with ESMTP id S20039612AbXBOBrq (ORCPT ); Thu, 15 Feb 2007 01:47:46 +0000 Received: by py-out-1112.google.com with SMTP id u52so177306pyb for ; Wed, 14 Feb 2007 17:46:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:from:to:subject:date:message-id:mime-version:content-type:content-transfer-encoding:x-mailer:thread-index:x-mimeole; b=N7aZu8iMrN1fslamiPTY7/9y33Z2aERkQlmFxqNq8UVjKgZU9HQHhzgijv8tGh/tJQdX3o+Yr/4CsKTiLdCu2ij9O6fHPF1QlpzKjL+4enrV6BUx2Ri1ZjVqc6xx/va9WJqsruZz9XK0c6NqG0Mv2h6mgB0mCK9oVxJzift5coI= Received: by 10.35.96.11 with SMTP id y11mr2183451pyl.1171504004210; Wed, 14 Feb 2007 17:46:44 -0800 (PST) Received: from barrioswindows ( [210.94.41.89]) by mx.google.com with ESMTP id v15sm1982342pyh.2007.02.14.17.46.42; Wed, 14 Feb 2007 17:46:43 -0800 (PST) From: =?ks_c_5601-1987?B?sei5zsL5?= To: Subject: Who know latest Linux/MIPS ABI ? Date: Thu, 15 Feb 2007 10:46:39 +0900 Message-ID: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> MIME-Version: 1.0 Content-Type: text/plain; charset="ks_c_5601-1987" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcdNh6W+t9WKjDKCRnu/wrGp7uYg0QCZh/TwAC1SM/A= X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.3028 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14094 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: barrioskmc@gmail.com Precedence: bulk X-list: linux-mips I want to know ELF format well in MIPS architecture. But in case of elf spec document on net, it had explained about i386. so I can't find specific sections about MIPS ELF. For example, Sections (.MIPS.stubs, .jcr, .pdr ) and so on. There is a MIPS ABI document in linux-mips.org. But it is very obsolete. As I know, any vendor don't use obsolete system V ABI. Currently, Is any ABI using o32 or n32 and so on. I hope I get a latest MIPS ABI and ELF Spec on Linux/MIPS. Who know where I get it? Thanks in advance. From akpm@linux-foundation.org Thu Feb 15 04:42:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 04:42:28 +0000 (GMT) Received: from smtp.osdl.org ([65.172.181.24]:39302 "EHLO smtp.osdl.org") by ftp.linux-mips.org with ESMTP id S20027700AbXBOEmW (ORCPT ); Thu, 15 Feb 2007 04:42:22 +0000 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l1F4d5hB029303 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Wed, 14 Feb 2007 20:39:05 -0800 Received: from box (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id l1F4d3pD019904; Wed, 14 Feb 2007 20:39:04 -0800 Date: Wed, 14 Feb 2007 20:39:03 -0800 From: Andrew Morton To: Ralf Baechle Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-Id: <20070214203903.8d013170.akpm@linux-foundation.org> In-Reply-To: <20070214214226.GA17899@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.17; x86_64-unknown-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.176 $ X-Scanned-By: MIMEDefang 2.36 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14095 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: linux-mips On Wed, 14 Feb 2007 21:42:26 +0000 Ralf Baechle wrote: > Time for a little bit of dead horse flogging. > > On Mon, Mar 06, 2006 at 05:05:52PM -0800, Andrew Morton wrote: > > > > --- a/include/asm-generic/unaligned.h > > > +++ b/include/asm-generic/unaligned.h > > > @@ -78,7 +78,7 @@ static inline void __ustw(__u16 val, __u > > > > > > #define __get_unaligned(ptr, size) ({ \ > > > const void *__gu_p = ptr; \ > > > - __typeof__(*(ptr)) val; \ > > > + __u64 val; \ > > > switch (size) { \ > > > case 1: \ > > > val = *(const __u8 *)__gu_p; \ > > > @@ -95,7 +95,7 @@ static inline void __ustw(__u16 val, __u > > > default: \ > > > bad_unaligned_access_length(); \ > > > }; \ > > > - val; \ > > > + (__typeof__(*(ptr)))val; \ > > > }) > > > > > > #define __put_unaligned(val, ptr, size) \ > > > > I worry about what impact that change might have on code generation. > > Hopefully none, if gcc is good enough. > > > > But I cannot think of a better fix. > > It does inflate the code but back then we agreed to go for Atsushi's patch > because it was fairly obviously correct. This patch obviously is less > obvious but generates fairly decent, works for arbitrary data types and > cuts down the size of unaligned.h from 122 lines to 44 so it must be good. > > ... > > +#define get_unaligned(ptr) \ > +({ \ > + const struct { \ > + union { \ > + const int __un_foo[0]; \ > + const __typeof__(*(ptr)) __un; \ > + } __un __attribute__ ((packed)); \ > + } * const __gu_p = (void *) (ptr); \ > + \ > + __gu_p->__un.__un; \ > }) Can someone please tell us how this magic works? (And it does appear to work). It seems to assuming that the compiler will assume that members of packed structures can have arbitrary alignment, even if that alignment is obvious. Which makes sense, but I'd like to see chapter-and-verse from the spec or from the gcc docs so we can rely upon it working on all architectures and compilers from now until ever more. IOW: your changlogging sucks ;) From marcel@holtmann.org Thu Feb 15 08:35:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 08:35:37 +0000 (GMT) Received: from coyote.holtmann.net ([217.160.111.169]:27012 "EHLO mail.holtmann.net") by ftp.linux-mips.org with ESMTP id S20037889AbXBOIfc (ORCPT ); Thu, 15 Feb 2007 08:35:32 +0000 Received: from [192.168.5.242] (p5487F978.dip.t-dialin.net [84.135.249.120]) by mail.holtmann.net (8.13.4/8.13.4/Debian-3sarge3) with ESMTP id l1F8agZ3009536; Thu, 15 Feb 2007 09:36:42 +0100 Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. From: Marcel Holtmann To: Andrew Morton Cc: Ralf Baechle , Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org In-Reply-To: <20070214203903.8d013170.akpm@linux-foundation.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> Content-Type: text/plain Date: Thu, 15 Feb 2007 09:35:16 +0100 Message-Id: <1171528516.28302.30.camel@violet> Mime-Version: 1.0 X-Mailer: Evolution 2.9.91 Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14096 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: marcel@holtmann.org Precedence: bulk X-list: linux-mips Hi Andrew, > > +#define get_unaligned(ptr) \ > > +({ \ > > + const struct { \ > > + union { \ > > + const int __un_foo[0]; \ > > + const __typeof__(*(ptr)) __un; \ > > + } __un __attribute__ ((packed)); \ > > + } * const __gu_p = (void *) (ptr); \ > > + \ > > + __gu_p->__un.__un; \ > > }) > > Can someone please tell us how this magic works? (And it does appear to > work). > > It seems to assuming that the compiler will assume that members of packed > structures can have arbitrary alignment, even if that alignment is obvious. > > Which makes sense, but I'd like to see chapter-and-verse from the spec or > from the gcc docs so we can rely upon it working on all architectures and > compilers from now until ever more. I am far away from having any knowledge about the GCC internals and the reason why this code works, but I've been told the generic way of handling unaligned access is this: #define get_unaligned(ptr) \ ({ \ struct __attribute__((packed)) { \ typeof(*(ptr)) __v; \ } *__p = (void *) (ptr); \ __p->__v; \ }) #define put_unaligned(val, ptr) \ do { \ struct __attribute__((packed)) { \ typeof(*(ptr)) __v; \ } *__p = (void *) (ptr); \ __p->__v = (val); \ } while(0) Actually I am using this code in the Bluetooth userspace library for over two years now without any complaints. Regards Marcel From vagabon.xyz@gmail.com Thu Feb 15 08:37:57 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 08:38:02 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.235]:58385 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20037879AbXBOIh5 (ORCPT ); Thu, 15 Feb 2007 08:37:57 +0000 Received: by qb-out-0506.google.com with SMTP id e12so123916qba for ; Thu, 15 Feb 2007 00:36:56 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=HC1/13Pykf4h5QPJIgIkD65qZrlRK6DbftFvBIPAElUXgc2xmGvPuxfaHPTomU0P3XDu9khlBCIfC9zNwgYq1K1kwta3WZbEQMgMSnaUBWlAn9nP1vuj3HAk9XUyO6nu8cvoh78lmM27f0tQu9rjLM+bduqsQz5SZSgRFZLIm/w= Received: by 10.114.107.19 with SMTP id f19mr868106wac.1171528616148; Thu, 15 Feb 2007 00:36:56 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 15 Feb 2007 00:36:56 -0800 (PST) Message-ID: Date: Thu, 15 Feb 2007 09:36:56 +0100 From: "Franck Bui-Huu" To: "Atsushi Nemoto" Subject: Re: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Cc: ralf@linux-mips.org, linux-mips@linux-mips.org, macro@linux-mips.org In-Reply-To: <20070215.011420.15247947.anemo@mba.ocn.ne.jp> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070214.102801.41198530.nemoto@toshiba-tops.co.jp> <20070215.011420.15247947.anemo@mba.ocn.ne.jp> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14097 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/14/07, Atsushi Nemoto wrote: > Same here. I just think introducing one name is better than two name. > I also feel "make KBUILD_SYM32=0" is more consistent. > Yes I agree KBUILD_SYM32 seems better for command line usage but I think it won't be used widely unlike in code usage where KBUILD_64BIT_SYM32 is better because it's really self explaned and not ambigous: "build a 64 bits kernel with 32 bits symbols". And I think it's more important. -- Franck From ralf@linux-mips.org Thu Feb 15 12:34:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 12:34:48 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:51921 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038434AbXBOMer (ORCPT ); Thu, 15 Feb 2007 12:34:47 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1FCYUJn027186; Thu, 15 Feb 2007 12:34:31 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1FCYU8O027185; Thu, 15 Feb 2007 12:34:30 GMT Date: Thu, 15 Feb 2007 12:34:30 +0000 From: Ralf Baechle To: barrioskmc@gmail.com Cc: linux-mips@linux-mips.org Subject: Re: Who know latest Linux/MIPS ABI ? Message-ID: <20070215123430.GA26003@linux-mips.org> References: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14098 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 15, 2007 at 10:46:39AM +0900, ������ wrote: > I want to know ELF format well in MIPS architecture. > But in case of elf spec document on net, it had explained about i386. so I > can't find specific sections about MIPS ELF. For example, Sections > (.MIPS.stubs, .jcr, .pdr ) and so on. > > There is a MIPS ABI document in linux-mips.org. But it is very obsolete. As > I know, any vendor don't use obsolete system V ABI. Currently, Is any ABI > using o32 or n32 and so on. > > I hope I get a latest MIPS ABI and ELF Spec on Linux/MIPS. > Who know where I get it? The documentation situation is a bit mess. The SysV gABI and MIPS psABI document the ABI ELF flavour which actually is only a subset of what Linux/MIPS actually uses. For the extensions you can probably find individual papers and postings scattered over the net. Ralf From vagabon.xyz@gmail.com Thu Feb 15 13:05:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 13:05:46 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.224]:56463 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038467AbXBONFl (ORCPT ); Thu, 15 Feb 2007 13:05:41 +0000 Received: by hu-out-0506.google.com with SMTP id 27so233367hub for ; Thu, 15 Feb 2007 05:05:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=tWoEPalvw6JaXT0LHV+Tz8gQ8qN98UenVrJiTEmrYfnE+n8BBGt6y35EybP5MmS7omCt1aATH/RYJ6u+QrVSNiT+Onjf2kpxhyUSt38FTGuKlQVrTECZz3fvT4flK9Yr71lgCYFR4Bkht+PZ1qPSkTGlTm7ogp7I06qNXdeLJ7s= Received: by 10.48.210.20 with SMTP id i20mr1352954nfg.1171544708816; Thu, 15 Feb 2007 05:05:08 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id p45sm10464473nfa.2007.02.15.05.05.07; Thu, 15 Feb 2007 05:05:07 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id EE68A23F76F; Thu, 15 Feb 2007 14:04:20 +0100 (CET) To: linux-mips@linux-mips.org Subject: [PATCH 2/3] Automatically set CONFIG_BUILD_ELF64 Date: Thu, 15 Feb 2007 14:04:19 +0100 Message-Id: <1171544660166-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <11715446603241-git-send-email-fbuihuu@gmail.com> References: <11715446603241-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14099 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu We do not rely on user anymore to setup this config correctly. Instead we make our choice depending on the load address. If we want to force Kbuild to use ELF64 format whatever the load address we can still do: $ make BUILD_ELF32=no Signed-off-by: Franck Bui-Huu --- arch/mips/Kconfig | 15 --------------- arch/mips/Makefile | 23 ++++++++++++++++++++--- 2 files changed, 20 insertions(+), 18 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index 9ccaddc..21812da 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -2014,21 +2014,6 @@ source "fs/Kconfig.binfmt" config TRAD_SIGNALS bool -config BUILD_ELF64 - bool "Use 64-bit ELF format for building" - depends on 64BIT - help - A 64-bit kernel is usually built using the 64-bit ELF binary object - format as it's one that allows arbitrary 64-bit constructs. For - kernels that are loaded within the KSEG compatibility segments the - 32-bit ELF format can optionally be used resulting in a somewhat - smaller binary, but this option is not explicitly supported by the - toolchain and since binutils 2.14 it does not even work at all. - - Say Y to use the 64-bit format or N to use the 32-bit one. - - If unsure say Y. - config BINFMT_IRIX bool "Include IRIX binary compatibility" depends on CPU_BIG_ENDIAN && 32BIT && BROKEN diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 4240ca1..2e9ae19 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -60,9 +60,6 @@ vmlinux-32 = vmlinux.32 vmlinux-64 = vmlinux cflags-y += -mabi=64 -ifndef CONFIG_BUILD_ELF64 -cflags-y += $(call cc-option,-msym32) -endif endif @@ -614,6 +611,26 @@ else JIFFIES = jiffies_64 endif +# +# Automatically detect the build format. By default we choose +# the elf format according to the load address. +# We can always force a build with a 64-bits symbol format by +# passing 'BUILD_ELF32=no' option to the make's command line. +# +ifdef CONFIG_64BIT + ifndef BUILD_ELF32 + ifeq ($(shell expr $(load-y) \< 0xffffffff80000000), 0) + BUILD_ELF32 = y + endif + endif + + ifeq ($(BUILD_ELF32), y) + cflags-y += -msym32 + else + cflags-y += -DCONFIG_BUILD_ELF64 + endif +endif + AFLAGS += $(cflags-y) CFLAGS += $(cflags-y) -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Thu Feb 15 13:06:10 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 13:06:13 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.239]:20368 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038832AbXBONGJ (ORCPT ); Thu, 15 Feb 2007 13:06:09 +0000 Received: by hu-out-0506.google.com with SMTP id 22so215296hug for ; Thu, 15 Feb 2007 05:05:08 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:from; b=At1C+R8bfDFvViBLASjPBLrshu4lr/Klu3aYcNJHHOeEDqhxsEB3UefYB9xdKLGzruK9f4PADNB9CJHZdUvbqpu35M00/fQ9nXO8DDgvPA4BUskjaK3UA1RVbJVVprYiablYgtk/Duu4hQ8xyEKfpnWsPailnS2IZuIx04DvrGA= Received: by 10.49.41.12 with SMTP id t12mr1342997nfj.1171544708392; Thu, 15 Feb 2007 05:05:08 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id p45sm10464472nfa.2007.02.15.05.05.07; Thu, 15 Feb 2007 05:05:07 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id C2CFF23F76E; Thu, 15 Feb 2007 14:04:20 +0100 (CET) To: linux-mips@linux-mips.org Subject: [PATCH 1/3] Remove '-mno-explicit-relocs' option when CONFIG_BUILD_ELF64 Date: Thu, 15 Feb 2007 14:04:18 +0100 Message-Id: <11715446603241-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14100 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This patch removes '-mno-explicit-relocs' usage when CONFIG_BUILD_ELF64 is set since this option was only required with the old hack to truncate addresses at the assembly level where "-mabi=64 -Wa,-mabi=32" was used. This should yield a small code size improvement for inline assembly, where the R constraint is used. The idea is coming from Maciej . Signed-off-by: Franck Bui-Huu --- arch/mips/Makefile | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index c68b5d3..4240ca1 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -60,9 +60,7 @@ vmlinux-32 = vmlinux.32 vmlinux-64 = vmlinux cflags-y += -mabi=64 -ifdef CONFIG_BUILD_ELF64 -cflags-y += $(call cc-option,-mno-explicit-relocs) -else +ifndef CONFIG_BUILD_ELF64 cflags-y += $(call cc-option,-msym32) endif endif -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Thu Feb 15 13:06:36 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 13:06:42 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.230]:65135 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038862AbXBONGK (ORCPT ); Thu, 15 Feb 2007 13:06:10 +0000 Received: by qb-out-0506.google.com with SMTP id e12so146823qba for ; Thu, 15 Feb 2007 05:05:09 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:to:cc:subject:date:message-id:x-mailer:in-reply-to:references:from; b=EB/bAcGpbTGeD2bBvODRkgnOet45t2Rc5xZTT7BIu9wmB3am7wgn/679WyuNN/a1hpUgAgleeo0JoZi2FgQidpkk5RZR0yAwRipb1G0hwWhZ+uej34jWdedu3fMwaVvISJD78KrefJ9MP16JSpcrZddRvhH7SYpL4e1bA43NTvc= Received: by 10.64.208.20 with SMTP id f20mr2788926qbg.1171544709173; Thu, 15 Feb 2007 05:05:09 -0800 (PST) Received: from spoutnik.innova-card.com ( [81.252.61.1]) by mx.google.com with ESMTP id g1sm10495192nfe.2007.02.15.05.05.07; Thu, 15 Feb 2007 05:05:07 -0800 (PST) Received: by spoutnik.innova-card.com (Postfix, from userid 500) id 2206423F770; Thu, 15 Feb 2007 14:04:21 +0100 (CET) To: linux-mips@linux-mips.org Subject: [PATCH 3/3] Rename CONFIG_BUILD_ELF64 into KBUILD_64BIT_SYM32 Date: Thu, 15 Feb 2007 14:04:20 +0100 Message-Id: <11715446611812-git-send-email-fbuihuu@gmail.com> X-Mailer: git-send-email 1.4.4.3.ge6d4 In-Reply-To: <1171544660166-git-send-email-fbuihuu@gmail.com> References: <11715446603241-git-send-email-fbuihuu@gmail.com> <1171544660166-git-send-email-fbuihuu@gmail.com> From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14101 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This patch renames it for 3 reasons: - "CONFIG" pattern is used by Kconfig. Now this macro is no more defined by Kconfig but by Kbuild itself make this clear by translating "CONFIG" into "KBUILD". - "ELF32" word is improper because it is irrelevant to ELF format and it makes confusion with CONFIG_BOOT_ELF32. So translate it with SYM32. - Add "64BIT" part to make clear that this macro implies a 64 bits kernel. Signed-off-by: Franck Bui-Huu --- arch/mips/Makefile | 4 +--- include/asm-mips/page.h | 2 +- include/asm-mips/pgtable-64.h | 2 +- include/asm-mips/stackframe.h | 12 ++++++------ 4 files changed, 9 insertions(+), 11 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 2e9ae19..e61c73f 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -625,9 +625,7 @@ ifdef CONFIG_64BIT endif ifeq ($(BUILD_ELF32), y) - cflags-y += -msym32 - else - cflags-y += -DCONFIG_BUILD_ELF64 + cflags-y += -msym32 -DKBUILD_64BIT_SYM32 endif endif diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h index d3fbd83..23006f8 100644 --- a/include/asm-mips/page.h +++ b/include/asm-mips/page.h @@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; } pgprot_t; /* * __pa()/__va() should be used only during mem init. */ -#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64) +#ifdef KBUILD_64BIT_SYM32 #define __pa_page_offset(x) ((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0) #else #define __pa_page_offset(x) PAGE_OFFSET diff --git a/include/asm-mips/pgtable-64.h b/include/asm-mips/pgtable-64.h index a5b1871..0b603ee 100644 --- a/include/asm-mips/pgtable-64.h +++ b/include/asm-mips/pgtable-64.h @@ -104,7 +104,7 @@ #define VMALLOC_START MAP_BASE #define VMALLOC_END \ (VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE) -#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \ +#if defined(CONFIG_MODULES) && defined(KBUILD_64BIT_SYM32) && \ VMALLOC_START != CKSSEG /* Load modules into 32bit-compatible segment. */ #define MODULE_START CKSSEG diff --git a/include/asm-mips/stackframe.h b/include/asm-mips/stackframe.h index 1fae5dc..bfde702 100644 --- a/include/asm-mips/stackframe.h +++ b/include/asm-mips/stackframe.h @@ -70,14 +70,14 @@ #else MFC0 k0, CP0_CONTEXT #endif -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4) +#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32) + lui k1, %hi(kernelsp) +#else lui k1, %highest(kernelsp) daddiu k1, %higher(kernelsp) dsll k1, 16 daddiu k1, %hi(kernelsp) dsll k1, 16 -#else - lui k1, %hi(kernelsp) #endif LONG_SRL k0, PTEBASE_SHIFT LONG_ADDU k1, k0 @@ -95,14 +95,14 @@ .endm #else .macro get_saved_sp /* Uniprocessor variation */ -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4) +#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32) + lui k1, %hi(kernelsp) +#else lui k1, %highest(kernelsp) daddiu k1, %higher(kernelsp) dsll k1, k1, 16 daddiu k1, %hi(kernelsp) dsll k1, k1, 16 -#else - lui k1, %hi(kernelsp) #endif LONG_L k1, %lo(kernelsp)(k1) .endm -- 1.4.4.3.ge6d4 From vagabon.xyz@gmail.com Thu Feb 15 13:15:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 13:15:50 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.230]:1684 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038832AbXBONPp (ORCPT ); Thu, 15 Feb 2007 13:15:45 +0000 Received: by qb-out-0506.google.com with SMTP id e12so148021qba for ; Thu, 15 Feb 2007 05:14:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=EJJ9DehZ27e/LyhUoyifxo2FWANlnbkWKSoGdRtS5XPyPLw09N56dLQxULcZnvIkPc8RNwkaZchDUJ4l1CedE6lTcS/aV6qhpiytL7EqDmgGXBIAJ9SyqG/WRpnlR0XV0MZki9fL5FAn8KnWIVhKEtHkfEHbyezN5+pAVCrYONk= Received: by 10.115.61.1 with SMTP id o1mr948960wak.1171545283218; Thu, 15 Feb 2007 05:14:43 -0800 (PST) Received: by 10.114.136.11 with HTTP; Thu, 15 Feb 2007 05:14:43 -0800 (PST) Message-ID: Date: Thu, 15 Feb 2007 14:14:43 +0100 From: "Franck Bui-Huu" To: linux-mips@linux-mips.org Subject: Re: [PATCH 3/3] Rename CONFIG_BUILD_ELF64 into KBUILD_64BIT_SYM32 In-Reply-To: <11715446611812-git-send-email-fbuihuu@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <11715446603241-git-send-email-fbuihuu@gmail.com> <1171544660166-git-send-email-fbuihuu@gmail.com> <11715446611812-git-send-email-fbuihuu@gmail.com> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14102 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/15/07, Franck Bui-Huu wrote: > From: Franck Bui-Huu > > ifeq ($(BUILD_ELF32), y) > - cflags-y += -msym32 argh, it should be "BUILD_SYM32" here. I'm resending this patch. -- Franck From vagabon.xyz@gmail.com Thu Feb 15 13:23:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 13:23:36 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.237]:56480 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038920AbXBONX1 (ORCPT ); Thu, 15 Feb 2007 13:23:27 +0000 Received: by qb-out-0506.google.com with SMTP id e12so148878qba for ; Thu, 15 Feb 2007 05:22:26 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:references:in-reply-to:content-type:content-transfer-encoding:from; b=NMSH1oyzpFV1UO4tz6U3N/H6ROZZCl+tDD2+Z3/AlJJFzsBrEYJ2jnlft7ztDmnPsRCXl1HUtQ8IvqOgBBtkDtYjDHLTZpAUvdc+K85ViZTP3/V6T2o0+nSpzW1BWZIA/5iKWgZFwk7JiIqdzz8D6WoHuLH4yWeZUrzGfssg35c= Received: by 10.64.210.3 with SMTP id i3mr2802457qbg.1171545746773; Thu, 15 Feb 2007 05:22:26 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id h1sm1132653nfe.2007.02.15.05.22.25; Thu, 15 Feb 2007 05:22:26 -0800 (PST) Message-ID: <45D45E60.40207@innova-card.com> Date: Thu, 15 Feb 2007 14:21:36 +0100 Reply-To: franck.bui-huu@innova-card.com User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips@linux-mips.org, Atsushi Nemoto , "Maciej W. Rozycki" Subject: [PATCH 3/3] Rename CONFIG_BUILD_ELF64 into KBUILD_64BIT_SYM32 References: <11715446603241-git-send-email-fbuihuu@gmail.com> <1171544660166-git-send-email-fbuihuu@gmail.com> <11715446611812-git-send-email-fbuihuu@gmail.com> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14103 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu This patch renames it for 3 reasons: - "CONFIG" pattern is used by Kconfig. Now this macro is no more defined by Kconfig but by Kbuild itself make this clear by translating "CONFIG" into "KBUILD". - "ELF32" word is improper because it is irrelevant to ELF format and it makes confusion with CONFIG_BOOT_ELF32. So translate it with SYM32. - Add "64BIT" part to make clear that this macro implies a 64 bits kernel. Signed-off-by: Franck Bui-Huu --- arch/mips/Makefile | 12 +++++------- include/asm-mips/page.h | 2 +- include/asm-mips/pgtable-64.h | 2 +- include/asm-mips/stackframe.h | 12 ++++++------ 4 files changed, 13 insertions(+), 15 deletions(-) diff --git a/arch/mips/Makefile b/arch/mips/Makefile index 2e9ae19..dcd9acc 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -615,19 +615,17 @@ endif # Automatically detect the build format. By default we choose # the elf format according to the load address. # We can always force a build with a 64-bits symbol format by -# passing 'BUILD_ELF32=no' option to the make's command line. +# passing 'KBUILD_SYM32=no' option to the make's command line. # ifdef CONFIG_64BIT - ifndef BUILD_ELF32 + ifndef KBUILD_SYM32 ifeq ($(shell expr $(load-y) \< 0xffffffff80000000), 0) - BUILD_ELF32 = y + KBUILD_SYM32 = y endif endif - ifeq ($(BUILD_ELF32), y) - cflags-y += -msym32 - else - cflags-y += -DCONFIG_BUILD_ELF64 + ifeq ($(KBUILD_SYM32), y) + cflags-y += -msym32 -DKBUILD_64BIT_SYM32 endif endif diff --git a/include/asm-mips/page.h b/include/asm-mips/page.h index d3fbd83..23006f8 100644 --- a/include/asm-mips/page.h +++ b/include/asm-mips/page.h @@ -149,7 +149,7 @@ typedef struct { unsigned long pgprot; } pgprot_t; /* * __pa()/__va() should be used only during mem init. */ -#if defined(CONFIG_64BIT) && !defined(CONFIG_BUILD_ELF64) +#ifdef KBUILD_64BIT_SYM32 #define __pa_page_offset(x) ((unsigned long)(x) < CKSEG0 ? PAGE_OFFSET : CKSEG0) #else #define __pa_page_offset(x) PAGE_OFFSET diff --git a/include/asm-mips/pgtable-64.h b/include/asm-mips/pgtable-64.h index a5b1871..0b603ee 100644 --- a/include/asm-mips/pgtable-64.h +++ b/include/asm-mips/pgtable-64.h @@ -104,7 +104,7 @@ #define VMALLOC_START MAP_BASE #define VMALLOC_END \ (VMALLOC_START + PTRS_PER_PGD * PTRS_PER_PMD * PTRS_PER_PTE * PAGE_SIZE) -#if defined(CONFIG_MODULES) && !defined(CONFIG_BUILD_ELF64) && \ +#if defined(CONFIG_MODULES) && defined(KBUILD_64BIT_SYM32) && \ VMALLOC_START != CKSSEG /* Load modules into 32bit-compatible segment. */ #define MODULE_START CKSSEG diff --git a/include/asm-mips/stackframe.h b/include/asm-mips/stackframe.h index 1fae5dc..bfde702 100644 --- a/include/asm-mips/stackframe.h +++ b/include/asm-mips/stackframe.h @@ -70,14 +70,14 @@ #else MFC0 k0, CP0_CONTEXT #endif -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4) +#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32) + lui k1, %hi(kernelsp) +#else lui k1, %highest(kernelsp) daddiu k1, %higher(kernelsp) dsll k1, 16 daddiu k1, %hi(kernelsp) dsll k1, 16 -#else - lui k1, %hi(kernelsp) #endif LONG_SRL k0, PTEBASE_SHIFT LONG_ADDU k1, k0 @@ -95,14 +95,14 @@ .endm #else .macro get_saved_sp /* Uniprocessor variation */ -#if defined(CONFIG_BUILD_ELF64) || (defined(CONFIG_64BIT) && __GNUC__ < 4) +#if defined(CONFIG_32BIT) || defined(KBUILD_64BIT_SYM32) + lui k1, %hi(kernelsp) +#else lui k1, %highest(kernelsp) daddiu k1, %higher(kernelsp) dsll k1, k1, 16 daddiu k1, %hi(kernelsp) dsll k1, k1, 16 -#else - lui k1, %hi(kernelsp) #endif LONG_L k1, %lo(kernelsp)(k1) .endm -- 1.4.4.3.ge6d4 From ralf@linux-mips.org Thu Feb 15 14:34:45 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 14:34:48 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:16091 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20039324AbXBOOep (ORCPT ); Thu, 15 Feb 2007 14:34:45 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1FEYhgC025615; Thu, 15 Feb 2007 14:34:44 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1FEYfHu025614; Thu, 15 Feb 2007 14:34:41 GMT Date: Thu, 15 Feb 2007 14:34:41 +0000 From: Ralf Baechle To: Andrew Morton Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-ID: <20070215143441.GA18155@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070214203903.8d013170.akpm@linux-foundation.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14104 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Wed, Feb 14, 2007 at 08:39:03PM -0800, Andrew Morton wrote: > Can someone please tell us how this magic works? (And it does appear to > work). > > It seems to assuming that the compiler will assume that members of packed > structures can have arbitrary alignment, even if that alignment is obvious. > > Which makes sense, but I'd like to see chapter-and-verse from the spec or > from the gcc docs so we can rely upon it working on all architectures and > compilers from now until ever more. > > IOW: your changlogging sucks ;) It was my entry for the next edition of the C Puzzle Book ;-) The whole union thing was only needed to get rid of a warning but Marcel's solution does the same thing by attaching the packed keyword to the entire structure instead, so this patch is now using his macros but using __packed instead. Ralf Signed-off-by: Ralf Baechle diff --git a/include/asm-generic/unaligned.h b/include/asm-generic/unaligned.h index 09ec447..60d94fc 100644 --- a/include/asm-generic/unaligned.h +++ b/include/asm-generic/unaligned.h @@ -1,122 +1,27 @@ -#ifndef _ASM_GENERIC_UNALIGNED_H_ -#define _ASM_GENERIC_UNALIGNED_H_ - -/* - * For the benefit of those who are trying to port Linux to another - * architecture, here are some C-language equivalents. - * - * This is based almost entirely upon Richard Henderson's - * asm-alpha/unaligned.h implementation. Some comments were - * taken from David Mosberger's asm-ia64/unaligned.h header. - */ - -#include - -/* - * The main single-value unaligned transfer routines. - */ -#define get_unaligned(ptr) \ - __get_unaligned((ptr), sizeof(*(ptr))) -#define put_unaligned(x,ptr) \ - __put_unaligned((__u64)(x), (ptr), sizeof(*(ptr))) - /* - * This function doesn't actually exist. The idea is that when - * someone uses the macros below with an unsupported size (datatype), - * the linker will alert us to the problem via an unresolved reference - * error. + * This file is subject to the terms and conditions of the GNU General Public + * License. See the file "COPYING" in the main directory of this archive + * for more details. */ -extern void bad_unaligned_access_length(void) __attribute__((noreturn)); - -struct __una_u64 { __u64 x __attribute__((packed)); }; -struct __una_u32 { __u32 x __attribute__((packed)); }; -struct __una_u16 { __u16 x __attribute__((packed)); }; - -/* - * Elemental unaligned loads - */ - -static inline __u64 __uldq(const __u64 *addr) -{ - const struct __una_u64 *ptr = (const struct __una_u64 *) addr; - return ptr->x; -} - -static inline __u32 __uldl(const __u32 *addr) -{ - const struct __una_u32 *ptr = (const struct __una_u32 *) addr; - return ptr->x; -} - -static inline __u16 __uldw(const __u16 *addr) -{ - const struct __una_u16 *ptr = (const struct __una_u16 *) addr; - return ptr->x; -} - -/* - * Elemental unaligned stores - */ - -static inline void __ustq(__u64 val, __u64 *addr) -{ - struct __una_u64 *ptr = (struct __una_u64 *) addr; - ptr->x = val; -} - -static inline void __ustl(__u32 val, __u32 *addr) -{ - struct __una_u32 *ptr = (struct __una_u32 *) addr; - ptr->x = val; -} +#ifndef __ASM_GENERIC_UNALIGNED_H +#define __ASM_GENERIC_UNALIGNED_H -static inline void __ustw(__u16 val, __u16 *addr) -{ - struct __una_u16 *ptr = (struct __una_u16 *) addr; - ptr->x = val; -} +#include -#define __get_unaligned(ptr, size) ({ \ - const void *__gu_p = ptr; \ - __u64 val; \ - switch (size) { \ - case 1: \ - val = *(const __u8 *)__gu_p; \ - break; \ - case 2: \ - val = __uldw(__gu_p); \ - break; \ - case 4: \ - val = __uldl(__gu_p); \ - break; \ - case 8: \ - val = __uldq(__gu_p); \ - break; \ - default: \ - bad_unaligned_access_length(); \ - }; \ - (__typeof__(*(ptr)))val; \ +#define get_unaligned(ptr) \ +({ \ + struct __packed { \ + typeof(*(ptr)) __v; \ + } *__p = (void *) (ptr); \ + __p->__v; \ }) -#define __put_unaligned(val, ptr, size) \ -do { \ - void *__gu_p = ptr; \ - switch (size) { \ - case 1: \ - *(__u8 *)__gu_p = val; \ - break; \ - case 2: \ - __ustw(val, __gu_p); \ - break; \ - case 4: \ - __ustl(val, __gu_p); \ - break; \ - case 8: \ - __ustq(val, __gu_p); \ - break; \ - default: \ - bad_unaligned_access_length(); \ - }; \ +#define put_unaligned(val, ptr) \ +do { \ + struct __packed { \ + typeof(*(ptr)) __v; \ + } *__p = (void *) (ptr); \ + __p->__v = (val); \ } while(0) -#endif /* _ASM_GENERIC_UNALIGNED_H */ +#endif /* __ASM_GENERIC_UNALIGNED_H */ From anemo@mba.ocn.ne.jp Thu Feb 15 16:57:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 16:57:33 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:4315 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20039426AbXBOQ51 (ORCPT ); Thu, 15 Feb 2007 16:57:27 +0000 Received: from localhost (p8089-ipad32funabasi.chiba.ocn.ne.jp [221.189.140.89]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id DC064A000 for ; Fri, 16 Feb 2007 01:54:35 +0900 (JST) Date: Fri, 16 Feb 2007 01:54:35 +0900 (JST) Message-Id: <20070216.015435.74752851.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: Re: [MIPS] Iomap implementation. From: Atsushi Nemoto In-Reply-To: References: X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14105 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 14 Feb 2007 19:36:09 +0000, linux-mips@linux-mips.org wrote: > This implementation has support for the concept of one separate ioport > address space by PCI domain. A pointer to the virtual address where > the port space of a domain has been mapped has been added to struct > pci_controller and systems should be fixed to fill in this value. For > single domain systems this will be the same value as passed to > set_io_port_base(). > > Signed-off-by: Ralf Baechle Compiling qemu kernel, I got: arch/mips/lib/built-in.o: In function `pci_iomap': (.text+0x2b0): undefined reference to `pci_domain_nr' Should we add some #ifdef CONFIG_PCI to iomap.c, or provide dummy pci_domain_nr()? --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Thu Feb 15 18:03:32 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 18:03:37 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:13050 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S28573750AbXBOSDc (ORCPT ); Thu, 15 Feb 2007 18:03:32 +0000 Received: from localhost (p8089-ipad32funabasi.chiba.ocn.ne.jp [221.189.140.89]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id B3F1DBEB0; Fri, 16 Feb 2007 03:02:09 +0900 (JST) Date: Fri, 16 Feb 2007 03:02:09 +0900 (JST) Message-Id: <20070216.030209.93206265.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: linux-mips@linux-mips.org, ralf@linux-mips.org, macro@linux-mips.org Subject: Re: [MIPS] Check FCSR for pending interrupts before restoring from a context. From: Atsushi Nemoto In-Reply-To: <20070214.170420.85684996.nemoto@toshiba-tops.co.jp> References: <20070209.015405.08319291.anemo@mba.ocn.ne.jp> <20070209.130316.14978798.nemoto@toshiba-tops.co.jp> <20070214.170420.85684996.nemoto@toshiba-tops.co.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14106 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Wed, 14 Feb 2007 17:04:20 +0900 (JST), Atsushi Nemoto wrote: > Subject: Check FCSR for pending interrupts, alternative version > > The commit 6d6671066a311703bca1b91645bb1e04cc983387 is incomplete and > misses non-r4k CPUs. This patch reverts the commit and fixes in other > way. > > * Do FCSR checking in caller of restore_fp_context. > * Send SIGFPE if the signal handler set any FPU exception bits. And this is for 2.6.20-stable tree. Signed-off-by: Atsushi Nemoto --- arch/mips/kernel/r4k_fpu.S | 16 -------------- arch/mips/kernel/signal-common.h | 35 ++++++++++++++++++++++++++++++- arch/mips/kernel/signal.c | 12 +++++++++- arch/mips/kernel/signal32.c | 41 +++++++++++++++++++++++++++++++++++-- arch/mips/kernel/signal_n32.c | 6 ++++- 5 files changed, 88 insertions(+), 22 deletions(-) diff --git a/arch/mips/kernel/r4k_fpu.S b/arch/mips/kernel/r4k_fpu.S index 59c1577..dbd42ad 100644 --- a/arch/mips/kernel/r4k_fpu.S +++ b/arch/mips/kernel/r4k_fpu.S @@ -114,14 +114,6 @@ LEAF(_save_fp_context32) */ LEAF(_restore_fp_context) EX lw t0, SC_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - #ifdef CONFIG_64BIT EX ldc1 $f1, SC_FPREGS+8(a0) EX ldc1 $f3, SC_FPREGS+24(a0) @@ -165,14 +157,6 @@ LEAF(_restore_fp_context) LEAF(_restore_fp_context32) /* Restore an o32 sigcontext. */ EX lw t0, SC32_FPC_CSR(a0) - - /* Fail if the CSR has exceptions pending */ - srl t1, t0, 5 - and t1, t0 - andi t1, 0x1f << 7 - bnez t1, fault - nop - EX ldc1 $f0, SC32_FPREGS+0(a0) EX ldc1 $f2, SC32_FPREGS+16(a0) EX ldc1 $f4, SC32_FPREGS+32(a0) diff --git a/arch/mips/kernel/signal-common.h b/arch/mips/kernel/signal-common.h index b1f09d5..0811298 100644 --- a/arch/mips/kernel/signal-common.h +++ b/arch/mips/kernel/signal-common.h @@ -66,6 +66,38 @@ out: } static inline int +fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static inline int +check_and_restore_fp_context(struct sigcontext __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context(sc); + return err ?: sig; +} + +static inline int restore_sigcontext(struct pt_regs *regs, struct sigcontext __user *sc) { unsigned int used_math; @@ -112,7 +144,8 @@ restore_sigcontext(struct pt_regs *regs, if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context(sc); + if (!err) + err = check_and_restore_fp_context(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); diff --git a/arch/mips/kernel/signal.c b/arch/mips/kernel/signal.c index b9d358e..c19408e 100644 --- a/arch/mips/kernel/signal.c +++ b/arch/mips/kernel/signal.c @@ -190,6 +190,7 @@ _sys_sigreturn(nabi_no_regargs struct pt { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -203,8 +204,11 @@ _sys_sigreturn(nabi_no_regargs struct pt recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->sf_sc)) + sig = restore_sigcontext(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... @@ -228,6 +232,7 @@ _sys_rt_sigreturn(nabi_no_regargs struct struct rt_sigframe __user *frame; sigset_t set; stack_t st; + int sig; frame = (struct rt_sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -241,8 +246,11 @@ _sys_rt_sigreturn(nabi_no_regargs struct recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); if (__copy_from_user(&st, &frame->rs_uc.uc_stack, sizeof(st))) goto badframe; diff --git a/arch/mips/kernel/signal32.c b/arch/mips/kernel/signal32.c index 7464df4..80ac070 100644 --- a/arch/mips/kernel/signal32.c +++ b/arch/mips/kernel/signal32.c @@ -321,6 +321,38 @@ asmlinkage int sys32_sigaltstack(nabi_no return ret; } +static inline int +fpcsr_pending(unsigned int __user *fpcsr) +{ + int err, sig = 0; + unsigned int csr, enabled; + + err = __get_user(csr, fpcsr); + enabled = FPU_CSR_UNI_X | ((csr & FPU_CSR_ALL_E) << 5); + /* + * If the signal handler set some FPU exceptions, clear it and + * send SIGFPE. + */ + if (csr & enabled) { + csr &= ~enabled; + err |= __put_user(csr, fpcsr); + sig = SIGFPE; + } + return err ?: sig; +} + +static inline int +check_and_restore_fp_context32(struct sigcontext32 __user *sc) +{ + int err, sig; + + err = sig = fpcsr_pending(&sc->sc_fpc_csr); + if (err > 0) + err = 0; + err |= restore_fp_context32(sc); + return err ?: sig; +} + static int restore_sigcontext32(struct pt_regs *regs, struct sigcontext32 __user *sc) { u32 used_math; @@ -367,7 +399,8 @@ static int restore_sigcontext32(struct p if (used_math()) { /* restore fpu context if we have used it before */ own_fpu(); - err |= restore_fp_context32(sc); + if (!err) + err = check_and_restore_fp_context32(sc); } else { /* signal handler may have used FPU. Give it up. */ lose_fpu(); @@ -464,6 +497,7 @@ _sys32_sigreturn(nabi_no_regargs struct { struct sigframe __user *frame; sigset_t blocked; + int sig; frame = (struct sigframe __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -477,8 +511,11 @@ _sys32_sigreturn(nabi_no_regargs struct recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext32(®s, &frame->sf_sc)) + sig = restore_sigcontext32(®s, &frame->sf_sc); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* * Don't let your children do this ... diff --git a/arch/mips/kernel/signal_n32.c b/arch/mips/kernel/signal_n32.c index d6160c9..617edd9 100644 --- a/arch/mips/kernel/signal_n32.c +++ b/arch/mips/kernel/signal_n32.c @@ -123,6 +123,7 @@ _sysn32_rt_sigreturn(nabi_no_regargs str sigset_t set; stack_t st; s32 sp; + int sig; frame = (struct rt_sigframe_n32 __user *) regs.regs[29]; if (!access_ok(VERIFY_READ, frame, sizeof(*frame))) @@ -136,8 +137,11 @@ _sysn32_rt_sigreturn(nabi_no_regargs str recalc_sigpending(); spin_unlock_irq(¤t->sighand->siglock); - if (restore_sigcontext(®s, &frame->rs_uc.uc_mcontext)) + sig = restore_sigcontext(®s, &frame->rs_uc.uc_mcontext); + if (sig < 0) goto badframe; + else if (sig) + force_sig(sig, current); /* The ucontext contains a stack32_t, so we must convert! */ if (__get_user(sp, &frame->rs_uc.uc_stack.ss_sp)) From stjeanma@pmc-sierra.com Thu Feb 15 20:01:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 20:01:48 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:26006 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039417AbXBOUBn (ORCPT ); Thu, 15 Feb 2007 20:01:43 +0000 Received: (qmail 12208 invoked by uid 101); 15 Feb 2007 19:27:07 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by mother.pmc-sierra.com with SMTP; 15 Feb 2007 19:27:07 -0000 Received: from pasqua.pmc-sierra.bc.ca (pasqua.pmc-sierra.bc.ca [134.87.183.161]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1FJR6i3020628; Thu, 15 Feb 2007 11:27:06 -0800 From: Marc St-Jean Received: (from stjeanma@localhost) by pasqua.pmc-sierra.bc.ca (8.13.4/8.12.11) id l1FJQT2o020816; Thu, 15 Feb 2007 13:26:29 -0600 Date: Thu, 15 Feb 2007 13:26:29 -0600 Message-Id: <200702151926.l1FJQT2o020816@pasqua.pmc-sierra.bc.ca> To: akpm@linux-foundation.org Subject: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14107 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stjeanma@pmc-sierra.com Precedence: bulk X-list: linux-mips Seventh attempt at the serial driver patch for the PMC-Sierra MSP71xx devices. There are three different fixes: 1. Fix for DesignWare APB THRE errata: In brief, this is a non-standard 16550 in that the THRE interrupt will not re-assert itself simply by disabling and re-enabling the THRI bit in the IER, it is only re-enabled if a character is actually sent out. It appears that the "8250-uart-backup-timer.patch" in the "mm" tree also fixes it so we have dropped our initial workaround. This patch now needs to be applied on top of that "mm" patch. 2. Fix for Busy Detect on LCR write: The DesignWare APB UART has a feature which causes a new Busy Detect interrupt to be generated if it's busy when the LCR is written. This fix saves the value of the LCR and rewrites it after clearing the interrupt. 3. Workaround for interrupt/data concurrency issue: The SoC needs to ensure that writes that can cause interrupts to be cleared reach the UART before returning from the ISR. This fix reads a non-destructive register on the UART so the read transaction completion ensures the previously queued write transaction has also completed. The differences from the last attempt is dropping the call to in_irq() and including more detailed description of the fixes. Thanks, Marc Signed-off-by: Marc St-Jean diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 3d91bfc..bfaacc5 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar return inb(up->port.iobase + 1); case UPIO_MEM: + case UPIO_DWAPB: return readb(up->port.membase + offset); case UPIO_MEM32: @@ -333,6 +334,8 @@ #endif static void serial_out(struct uart_8250_port *up, int offset, int value) { + /* Save the offset before it's remapped */ + int save_offset = offset; offset = map_8250_out_reg(up, offset) << up->port.regshift; switch (up->port.iotype) { @@ -359,6 +362,18 @@ #endif writeb(value, up->port.membase + offset); break; + case UPIO_DWAPB: + /* Save the LCR value so it can be re-written when a + * Busy Detect interrupt occurs. */ + if (save_offset == UART_LCR) + up->lcr = value; + writeb(value, up->port.membase + offset); + /* Read the IER to ensure any interrupt is cleared before + * returning from ISR. */ + if (save_offset == UART_TX || save_offset == UART_IER) + value = serial_in(up, UART_IER); + break; + default: outb(value, up->port.iobase + offset); } @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u #ifdef CONFIG_SERIAL_8250_AU1X00 case UPIO_AU: #endif + case UPIO_DWAPB: serial_out(up, offset, value); (void)serial_in(up, UART_LCR); /* safe, no side-effects */ break; @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( handled = 1; end = NULL; + } else if (up->port.iotype == UPIO_DWAPB && + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { + /* The DesignWare APB UART has an Busy Detect (0x07) + * interrupt meaning an LCR write attempt occured while the + * UART was busy. The interrupt must be cleared by reading + * the UART status register (USR) and the LCR re-written. */ + unsigned int status; + status = *(volatile u32 *)up->port.private_data; + serial_out(up, UART_LCR, up->lcr); + + handled = 1; + + end = NULL; } else if (end == NULL) end = l; @@ -2085,6 +2114,7 @@ static int serial8250_request_std_resour case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2122,6 +2152,7 @@ static void serial8250_release_std_resou case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2454,8 +2485,8 @@ int __init serial8250_start_console(stru add_preferred_console("ttyS", line, options); printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : + line, port->iotype >= UPIO_MEM ? "MMIO" : "I/O port", + port->iotype >= UPIO_MEM ? (unsigned long) port->mapbase : (unsigned long) port->iobase, options); if (!(serial8250_console.flags & CON_ENABLED)) { serial8250_console.flags &= ~CON_PRINTBUFFER; diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c index f84982e..f5b6036 100644 --- a/drivers/serial/serial_core.c +++ b/drivers/serial/serial_core.c @@ -2057,6 +2057,7 @@ uart_report_port(struct uart_driver *drv case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: snprintf(address, sizeof(address), "MMIO 0x%lx", port->mapbase); break; @@ -2401,6 +2402,7 @@ int uart_match_port(struct uart_port *po case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: return (port1->mapbase == port2->mapbase); } return 0; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index cf23813..8cdd326 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -230,6 +230,7 @@ #define UPIO_MEM (2) #define UPIO_MEM32 (3) #define UPIO_AU (4) /* Au1x00 type IO */ #define UPIO_TSI (5) /* Tsi108/109 type IO */ +#define UPIO_DWAPB (6) /* DesignWare APB UART */ unsigned int read_status_mask; /* driver specific */ unsigned int ignore_status_mask; /* driver specific */ @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( struct device *dev; /* parent device */ unsigned char hub6; /* this should be in the 8250 driver */ unsigned char unused[3]; + void *private_data; /* generic platform data pointer */ }; /* diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 3c8a6aa..1c5ed7d 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -38,6 +38,8 @@ #define UART_IIR_THRI 0x02 /* Transmitt #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ + #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ From sshtylyov@ru.mvista.com Thu Feb 15 20:32:16 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 20:32:20 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:6568 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20027651AbXBOUcQ (ORCPT ); Thu, 15 Feb 2007 20:32:16 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id BEEAE3EC9; Thu, 15 Feb 2007 12:31:38 -0800 (PST) Message-ID: <45D4C324.1000106@ru.mvista.com> Date: Thu, 15 Feb 2007 23:31:32 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Marc St-Jean Cc: akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master References: <200702151926.l1FJQT2o020816@pasqua.pmc-sierra.bc.ca> In-Reply-To: <200702151926.l1FJQT2o020816@pasqua.pmc-sierra.bc.ca> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14108 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Marc St-Jean wrote: > There are three different fixes: > 1. Fix for DesignWare APB THRE errata: > In brief, this is a non-standard 16550 in that the THRE interrupt > will not re-assert itself simply by disabling and re-enabling the > THRI bit in the IER, it is only re-enabled if a character is actually > sent out. > It appears that the "8250-uart-backup-timer.patch" in the "mm" tree also > fixes it so we have dropped our initial workaround. > This patch now needs to be applied on top of that "mm" patch. This patch has hit the mainline kernel already. > 2. Fix for Busy Detect on LCR write: > The DesignWare APB UART has a feature which causes a new Busy Detect > interrupt to be generated if it's busy when the LCR is written. This > fix saves the value of the LCR and rewrites it after clearing the > interrupt. > 3. Workaround for interrupt/data concurrency issue: > The SoC needs to ensure that writes that can cause interrupts to be > cleared reach the UART before returning from the ISR. This fix reads > a non-destructive register on the UART so the read transaction > completion ensures the previously queued write transaction has > also completed. > The differences from the last attempt is dropping the call to > in_irq() and including more detailed description of the fixes. The difference part would better be under the "---" cutoff line, along with diffstat. This way it gets auto-removed by quilt/git when applying the patch. > Signed-off-by: Marc St-Jean > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c > index 3d91bfc..bfaacc5 100644 > --- a/drivers/serial/8250.c > +++ b/drivers/serial/8250.c > @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar > return inb(up->port.iobase + 1); > > case UPIO_MEM: > + case UPIO_DWAPB: > return readb(up->port.membase + offset); > > case UPIO_MEM32: > @@ -333,6 +334,8 @@ #endif > static void > serial_out(struct uart_8250_port *up, int offset, int value) > { > + /* Save the offset before it's remapped */ > + int save_offset = offset; > offset = map_8250_out_reg(up, offset) << up->port.regshift; > > switch (up->port.iotype) { I've just got an idea how to "beautify" this code -- rename the 'offset' arg to something like reg, and then declare/init 'offset' as local variable. Would certainly look better (and worth doing in all serial_* accessros). > @@ -359,6 +362,18 @@ #endif > writeb(value, up->port.membase + offset); > break; > > + case UPIO_DWAPB: > + /* Save the LCR value so it can be re-written when a > + * Busy Detect interrupt occurs. */ > + if (save_offset == UART_LCR) > + up->lcr = value; > + writeb(value, up->port.membase + offset); > + /* Read the IER to ensure any interrupt is cleared before > + * returning from ISR. */ > + if (save_offset == UART_TX || save_offset == UART_IER) > + value = serial_in(up, UART_IER); > + break; > + > default: > outb(value, up->port.iobase + offset); > } > @@ -2454,8 +2485,8 @@ int __init serial8250_start_console(stru > > add_preferred_console("ttyS", line, options); > printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", > - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", > - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : > + line, port->iotype >= UPIO_MEM ? "MMIO" : "I/O port", > + port->iotype >= UPIO_MEM ? (unsigned long) port->mapbase : > (unsigned long) port->iobase, options); > if (!(serial8250_console.flags & CON_ENABLED)) { > serial8250_console.flags &= ~CON_PRINTBUFFER; I've remembered why I decided not to fix it: this code only gets called from 8250__eraly.c which can't handle anything beyond UPIO_MEM anyway. WBR, Sergei From akpm@linux-foundation.org Thu Feb 15 21:57:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 21:57:45 +0000 (GMT) Received: from smtp.osdl.org ([65.172.181.24]:42892 "EHLO smtp.osdl.org") by ftp.linux-mips.org with ESMTP id S20037484AbXBOV5P (ORCPT ); Thu, 15 Feb 2007 21:57:15 +0000 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l1FLrwhB029022 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Feb 2007 13:53:59 -0800 Received: from akpm.corp.google.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id l1FLrwK4009853; Thu, 15 Feb 2007 13:53:58 -0800 Date: Thu, 15 Feb 2007 13:53:58 -0800 From: Andrew Morton To: Ralf Baechle Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-Id: <20070215135358.020781dd.akpm@linux-foundation.org> In-Reply-To: <20070215143441.GA18155@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.176 $ X-Scanned-By: MIMEDefang 2.36 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14109 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: linux-mips On Thu, 15 Feb 2007 14:34:41 +0000 Ralf Baechle wrote: > On Wed, Feb 14, 2007 at 08:39:03PM -0800, Andrew Morton wrote: > > > Can someone please tell us how this magic works? (And it does appear to > > work). > > > > It seems to assuming that the compiler will assume that members of packed > > structures can have arbitrary alignment, even if that alignment is obvious. > > > > Which makes sense, but I'd like to see chapter-and-verse from the spec or > > from the gcc docs so we can rely upon it working on all architectures and > > compilers from now until ever more. > > > > IOW: your changlogging sucks ;) > > It was my entry for the next edition of the C Puzzle Book ;-) > > The whole union thing was only needed to get rid of a warning but Marcel's > solution does the same thing by attaching the packed keyword to the entire > structure instead, so this patch is now using his macros but using __packed > instead. How do we know this trick will work as-designed across all versions of gcc and icc (at least) and for all architectures and for all sets of compiler options? Basically, it has to be guaranteed by a C standard. Is it? From ralf@linux-mips.org Thu Feb 15 22:18:43 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 22:18:44 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:37273 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037553AbXBOWSn (ORCPT ); Thu, 15 Feb 2007 22:18:43 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1FMIfZp014744; Thu, 15 Feb 2007 22:18:42 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1FMIdGY014743; Thu, 15 Feb 2007 22:18:39 GMT Date: Thu, 15 Feb 2007 22:18:39 +0000 From: Ralf Baechle To: Andrew Morton Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-ID: <20070215221839.GA14103@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070215135358.020781dd.akpm@linux-foundation.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14110 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 15, 2007 at 01:53:58PM -0800, Andrew Morton wrote: > > The whole union thing was only needed to get rid of a warning but Marcel's > > solution does the same thing by attaching the packed keyword to the entire > > structure instead, so this patch is now using his macros but using __packed > > instead. > > How do we know this trick will work as-designed across all versions of gcc > and icc (at least) and for all architectures and for all sets of compiler > options? > > Basically, it has to be guaranteed by a C standard. Is it? Gcc info page says: [...] `packed' The `packed' attribute specifies that a variable or structure field should have the smallest possible alignment--one byte for a variable, and one bit for a field, unless you specify a larger value with the `aligned' attribute. [...] Qed? Ralf From jeremy@goop.org Thu Feb 15 23:06:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 23:06:36 +0000 (GMT) Received: from gw.goop.org ([64.81.55.164]:56526 "EHLO mail.goop.org") by ftp.linux-mips.org with ESMTP id S20037601AbXBOXGb (ORCPT ); Thu, 15 Feb 2007 23:06:31 +0000 Received: by lurch.goop.org (Postfix, from userid 525) id E55C72C8044; Thu, 15 Feb 2007 15:05:22 -0800 (PST) Received: from lurch.goop.org (localhost [127.0.0.1]) by lurch.goop.org (Postfix) with ESMTP id 21B2B2C803F; Thu, 15 Feb 2007 15:05:22 -0800 (PST) Received: from [192.168.3.174] (dsl001-150-252.sfo1.dsl.speakeasy.net [72.1.150.252]) by lurch.goop.org (Postfix) with ESMTP; Thu, 15 Feb 2007 15:05:22 -0800 (PST) Message-ID: <45D4E740.9020504@goop.org> Date: Thu, 15 Feb 2007 15:05:36 -0800 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: Ralf Baechle CC: Andrew Morton , Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> <20070215221839.GA14103@linux-mips.org> In-Reply-To: <20070215221839.GA14103@linux-mips.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP by lurch.goop.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14111 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jeremy@goop.org Precedence: bulk X-list: linux-mips Ralf Baechle wrote: > Gcc info page says: > > [...] > `packed' > The `packed' attribute specifies that a variable or structure field > should have the smallest possible alignment--one byte for a > variable, and one bit for a field, unless you specify a larger > value with the `aligned' attribute. > [...] > > Qed? So that the compiler has to assume that if its accessing this __packed structure, it may be embedded unaligned within something else? And because the pointer is cast through (void *) it isn't allowed to use alias analysis to notice that the pointer wasn't originally (apparently) unaligned. Seems sound to me. J From akpm@linux-foundation.org Thu Feb 15 23:41:40 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Thu, 15 Feb 2007 23:41:45 +0000 (GMT) Received: from smtp.osdl.org ([65.172.181.24]:40599 "EHLO smtp.osdl.org") by ftp.linux-mips.org with ESMTP id S20037648AbXBOXlk (ORCPT ); Thu, 15 Feb 2007 23:41:40 +0000 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l1FNcOhB032352 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Feb 2007 15:38:24 -0800 Received: from akpm.corp.google.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id l1FNcNqp012309; Thu, 15 Feb 2007 15:38:24 -0800 Date: Thu, 15 Feb 2007 15:38:23 -0800 From: Andrew Morton To: Ralf Baechle Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-Id: <20070215153823.239fd616.akpm@linux-foundation.org> In-Reply-To: <20070215221839.GA14103@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> <20070215221839.GA14103@linux-mips.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.176 $ X-Scanned-By: MIMEDefang 2.36 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14112 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: linux-mips On Thu, 15 Feb 2007 22:18:39 +0000 Ralf Baechle wrote: > On Thu, Feb 15, 2007 at 01:53:58PM -0800, Andrew Morton wrote: > > > > The whole union thing was only needed to get rid of a warning but Marcel's > > > solution does the same thing by attaching the packed keyword to the entire > > > structure instead, so this patch is now using his macros but using __packed > > > instead. > > > > How do we know this trick will work as-designed across all versions of gcc > > and icc (at least) and for all architectures and for all sets of compiler > > options? > > > > Basically, it has to be guaranteed by a C standard. Is it? > > Gcc info page says: > > [...] > `packed' > The `packed' attribute specifies that a variable or structure field > should have the smallest possible alignment--one byte for a > variable, and one bit for a field, unless you specify a larger > value with the `aligned' attribute. > [...] > hm. So if I have struct bar { unsigned long b; } __attribute__((packed)); struct foo { unsigned long u; struct bar b; }; then the compiler can see that foo.b.b is well-aligned, regardless of the packedness. Plus some crazy people compile the kernel with icc (or at least they used to). What happens there? > Qed? worried. From jeremy@goop.org Fri Feb 16 00:14:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 00:14:47 +0000 (GMT) Received: from gw.goop.org ([64.81.55.164]:27624 "EHLO mail.goop.org") by ftp.linux-mips.org with ESMTP id S20037697AbXBPAOm (ORCPT ); Fri, 16 Feb 2007 00:14:42 +0000 Received: by lurch.goop.org (Postfix, from userid 525) id C482E2C8044; Thu, 15 Feb 2007 16:13:33 -0800 (PST) Received: from lurch.goop.org (localhost [127.0.0.1]) by lurch.goop.org (Postfix) with ESMTP id E67512C803F; Thu, 15 Feb 2007 16:13:32 -0800 (PST) Received: from [192.168.3.174] (dsl001-150-252.sfo1.dsl.speakeasy.net [72.1.150.252]) by lurch.goop.org (Postfix) with ESMTP; Thu, 15 Feb 2007 16:13:32 -0800 (PST) Message-ID: <45D4F735.1020106@goop.org> Date: Thu, 15 Feb 2007 16:13:41 -0800 From: Jeremy Fitzhardinge User-Agent: Thunderbird 1.5.0.9 (X11/20070212) MIME-Version: 1.0 To: Andrew Morton CC: Ralf Baechle , Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> <20070215221839.GA14103@linux-mips.org> <20070215153823.239fd616.akpm@linux-foundation.org> In-Reply-To: <20070215153823.239fd616.akpm@linux-foundation.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Scanned: ClamAV using ClamSMTP by lurch.goop.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14113 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: jeremy@goop.org Precedence: bulk X-list: linux-mips Andrew Morton wrote: > hm. So if I have > > struct bar { > unsigned long b; > } __attribute__((packed)); > > struct foo { > unsigned long u; > struct bar b; > }; > > then the compiler can see that foo.b.b is well-aligned, regardless of the > packedness. In Ralf's code, the structure is anonymous, and is used to declare a pointer type, which is initialized from a void *. So I think the compiler isn't allowed to assume anything about its alignment. J From ralf@linux-mips.org Fri Feb 16 00:43:20 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 00:43:22 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:12263 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20037758AbXBPAnU (ORCPT ); Fri, 16 Feb 2007 00:43:20 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1G0hJnm021963; Fri, 16 Feb 2007 00:43:19 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1G0hHMD021960; Fri, 16 Feb 2007 00:43:17 GMT Date: Fri, 16 Feb 2007 00:43:17 +0000 From: Ralf Baechle To: Andrew Morton Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-ID: <20070216004317.GA18987@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> <20070215221839.GA14103@linux-mips.org> <20070215153823.239fd616.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070215153823.239fd616.akpm@linux-foundation.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14114 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 15, 2007 at 03:38:23PM -0800, Andrew Morton wrote: > hm. So if I have > > struct bar { > unsigned long b; > } __attribute__((packed)); > > struct foo { > unsigned long u; > struct bar b; > }; > > then the compiler can see that foo.b.b is well-aligned, regardless of the > packedness. > > Plus some crazy people compile the kernel with icc (or at least they used > to). What happens there? A quick grep for __attribute__((packed)) and __packed find around 900 hits, I'd probably find more if I'd look for syntactical variations. Some hits are in arch/{i386,x86_64,ia64}. At a glance it seems hard to configure a useful x86 kernel that doesn't involve any packed attribute. I take that as statistical proof that icc either has doesn't really work for building the kernel or groks packing. Any compiler not implementing gcc extensions is lost at building the kernel but that's old news. Ralf From akpm@linux-foundation.org Fri Feb 16 01:13:56 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 01:14:01 +0000 (GMT) Received: from smtp.osdl.org ([65.172.181.24]:56227 "EHLO smtp.osdl.org") by ftp.linux-mips.org with ESMTP id S20037809AbXBPBN4 (ORCPT ); Fri, 16 Feb 2007 01:13:56 +0000 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l1G1AahB002841 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Feb 2007 17:10:36 -0800 Received: from akpm.corp.google.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id l1G1Aa7H015113; Thu, 15 Feb 2007 17:10:36 -0800 Date: Thu, 15 Feb 2007 17:10:35 -0800 From: Andrew Morton To: Marc St-Jean Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Message-Id: <20070215171035.83918aae.akpm@linux-foundation.org> In-Reply-To: <200702151926.l1FJQT2o020816@pasqua.pmc-sierra.bc.ca> References: <200702151926.l1FJQT2o020816@pasqua.pmc-sierra.bc.ca> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.176 $ X-Scanned-By: MIMEDefang 2.36 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14115 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: linux-mips On Thu, 15 Feb 2007 13:26:29 -0600 Marc St-Jean wrote: > + status = *(volatile u32 *)up->port.private_data; It distresses me that this patch uses a variable which this patch doesn't initialise anywhere. It isn't complete. The sub-driver code whch sets up this field shuld be included in the patch, no? From akpm@linux-foundation.org Fri Feb 16 01:30:37 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 01:30:42 +0000 (GMT) Received: from smtp.osdl.org ([65.172.181.24]:18597 "EHLO smtp.osdl.org") by ftp.linux-mips.org with ESMTP id S20037783AbXBPBah (ORCPT ); Fri, 16 Feb 2007 01:30:37 +0000 Received: from shell0.pdx.osdl.net (fw.osdl.org [65.172.181.6]) by smtp.osdl.org (8.12.8/8.12.8) with ESMTP id l1G1RLhB003260 (version=TLSv1/SSLv3 cipher=EDH-RSA-DES-CBC3-SHA bits=168 verify=NO); Thu, 15 Feb 2007 17:27:21 -0800 Received: from akpm.corp.google.com (shell0.pdx.osdl.net [10.9.0.31]) by shell0.pdx.osdl.net (8.13.1/8.11.6) with SMTP id l1G1RLi6015434; Thu, 15 Feb 2007 17:27:21 -0800 Date: Thu, 15 Feb 2007 17:27:20 -0800 From: Andrew Morton To: Ralf Baechle Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-Id: <20070215172720.3e9ce464.akpm@linux-foundation.org> In-Reply-To: <20070216004317.GA18987@linux-mips.org> References: <20050830104056.GA4710@linux-mips.org> <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> <20070215221839.GA14103@linux-mips.org> <20070215153823.239fd616.akpm@linux-foundation.org> <20070216004317.GA18987@linux-mips.org> X-Mailer: Sylpheed version 2.2.7 (GTK+ 2.8.6; i686-pc-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-MIMEDefang-Filter: osdl$Revision: 1.176 $ X-Scanned-By: MIMEDefang 2.36 Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14116 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: akpm@linux-foundation.org Precedence: bulk X-list: linux-mips On Fri, 16 Feb 2007 00:43:17 +0000 Ralf Baechle wrote: > On Thu, Feb 15, 2007 at 03:38:23PM -0800, Andrew Morton wrote: > > > hm. So if I have > > > > struct bar { > > unsigned long b; > > } __attribute__((packed)); > > > > struct foo { > > unsigned long u; > > struct bar b; > > }; > > > > then the compiler can see that foo.b.b is well-aligned, regardless of the > > packedness. > > > > Plus some crazy people compile the kernel with icc (or at least they used > > to). What happens there? > > A quick grep for __attribute__((packed)) and __packed find around 900 hits, > I'd probably find more if I'd look for syntactical variations. Some hits > are in arch/{i386,x86_64,ia64}. At a glance it seems hard to configure a > useful x86 kernel that doesn't involve any packed attribute. I take that > as statistical proof that icc either has doesn't really work for building > the kernel or groks packing. Any compiler not implementing gcc extensions > is lost at building the kernel but that's old news. > No, icc surely supports attribute(packed). My point is that we shouldn't rely upon the gcc info file for this, because other compilers can (or could) be used to build the kernel. So it would be safer if the C spec said (or could be interpreted to say) "members of packed structures are always copied bytewise". So then we can be reasonably confident that this change won't break the use of those compilers. But then, I don't even know if any C standard says anything about packing. Ho hum. Why are we talking about this, anyway? Does the patch make the code faster? Or just nicer? From ralf@linux-mips.org Fri Feb 16 01:59:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 01:59:40 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:4809 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S28573768AbXBPB7j (ORCPT ); Fri, 16 Feb 2007 01:59:39 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1G1xatq025701; Fri, 16 Feb 2007 01:59:37 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1G1xYac025700; Fri, 16 Feb 2007 01:59:34 GMT Date: Fri, 16 Feb 2007 01:59:34 +0000 From: Ralf Baechle To: Andrew Morton Cc: Atsushi Nemoto , linux-mips@linux-mips.org, linux-kernel@vger.kernel.org Subject: Re: [PATCH] Optimize generic get_unaligned / put_unaligned implementations. Message-ID: <20070216015934.GB18987@linux-mips.org> References: <20060306.203218.69025300.nemoto@toshiba-tops.co.jp> <20060306170552.0aab29c5.akpm@osdl.org> <20070214214226.GA17899@linux-mips.org> <20070214203903.8d013170.akpm@linux-foundation.org> <20070215143441.GA18155@linux-mips.org> <20070215135358.020781dd.akpm@linux-foundation.org> <20070215221839.GA14103@linux-mips.org> <20070215153823.239fd616.akpm@linux-foundation.org> <20070216004317.GA18987@linux-mips.org> <20070215172720.3e9ce464.akpm@linux-foundation.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20070215172720.3e9ce464.akpm@linux-foundation.org> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14117 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Thu, Feb 15, 2007 at 05:27:20PM -0800, Andrew Morton wrote: > No, icc surely supports attribute(packed). My point is that we shouldn't > rely upon the gcc info file for this, because other compilers can (or > could) be used to build the kernel. > > So it would be safer if the C spec said (or could be interpreted to say) > "members of packed structures are always copied bytewise". So then we > can be reasonably confident that this change won't break the use of > those compilers. > > But then, I don't even know if any C standard says anything about packing. Memory layout and alignment of structures and members are implementation defined according to the C standard; the standard provides no means to influence these. So it takes a compiler extension such as gcc's __attribute__(). > Ho hum. Why are we talking about this, anyway? Does the patch make the > code faster? Or just nicer? Smaller binary and from looking at the disassembly a tad faster also. Ralf From sshtylyov@ru.mvista.com Fri Feb 16 13:48:38 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 13:48:43 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:45253 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20038843AbXBPNsi (ORCPT ); Fri, 16 Feb 2007 13:48:38 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 0C1AC3EC9; Fri, 16 Feb 2007 05:48:03 -0800 (PST) Message-ID: <45D5B60F.7020104@ru.mvista.com> Date: Fri, 16 Feb 2007 16:47:59 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Andrew Morton Cc: Marc St-Jean , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master References: <200702151926.l1FJQT2o020816@pasqua.pmc-sierra.bc.ca> <20070215171035.83918aae.akpm@linux-foundation.org> In-Reply-To: <20070215171035.83918aae.akpm@linux-foundation.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14118 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Andrew Morton wrote: >>+ status = *(volatile u32 *)up->port.private_data; > It distresses me that this patch uses a variable which this patch > doesn't initialise anywhere. It isn't complete. I assume this gets passed via early_serial_setup(). Marc? > The sub-driver code whch sets up this field shuld be included in the > patch, no? Hardly so, this code (not a subdriver) resides under arch/mips/ I think. WBR, Sergei From vagabon.xyz@gmail.com Fri Feb 16 15:34:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 15:34:17 +0000 (GMT) Received: from hu-out-0506.google.com ([72.14.214.236]:26284 "EHLO hu-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038963AbXBPPeM (ORCPT ); Fri, 16 Feb 2007 15:34:12 +0000 Received: by hu-out-0506.google.com with SMTP id 27so428049hub for ; Fri, 16 Feb 2007 07:33:39 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:reply-to:user-agent:mime-version:to:cc:subject:content-type:content-transfer-encoding:from; b=Ltd+Q01BiwMNtXF5wdmQHqn9xGvOQqiLfUStHvrEzdnqLIGW5TkiXHoK1+W7dJFHGtldcgYISTG8Qldk4/P1vHknVJtJFCahKiZWdmiOHerBnI50ARcX3VWcxBPvYIOazJKMcTGBRrZ87aGo2InH8utItuFISOu6WDs6NsCXU18= Received: by 10.67.22.7 with SMTP id z7mr3068467ugi.1171640019187; Fri, 16 Feb 2007 07:33:39 -0800 (PST) Received: from ?192.168.0.24? ( [81.252.61.1]) by mx.google.com with ESMTP id c25sm3895691ika.2007.02.16.07.33.37; Fri, 16 Feb 2007 07:33:38 -0800 (PST) Message-ID: <45D5CEA5.3050604@innova-card.com> Date: Fri, 16 Feb 2007 16:32:53 +0100 Reply-To: Franck User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Ralf Baechle CC: linux-mips Subject: [PATCH] Fix __copy_{to,from}_user_inatomic Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit From: Franck Bui-Huu Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14119 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips From: Franck Bui-Huu These functions are aliases to __copy_{to,from}_user resp but they are not allowed to sleep. Therefore might_sleep() must not be used by their implementions. Signed-off-by: Franck Bui-Huu --- include/asm-mips/uaccess.h | 6 ++---- 1 files changed, 2 insertions(+), 4 deletions(-) diff --git a/include/asm-mips/uaccess.h b/include/asm-mips/uaccess.h index 825fcbd..fd01939 100644 --- a/include/asm-mips/uaccess.h +++ b/include/asm-mips/uaccess.h @@ -407,7 +407,7 @@ extern size_t __copy_user(void *__to, const void *__from, size_t __n); * @from: Source address, in kernel space. * @n: Number of bytes to copy. * - * Context: User context only. This function may sleep. + * Context: User context only. * * Copy data from kernel space to user space. Caller must check * the specified block with access_ok() before calling this function. @@ -421,7 +421,6 @@ extern size_t __copy_user(void *__to, const void *__from, size_t __n); const void *__cu_from; \ long __cu_len; \ \ - might_sleep(); \ __cu_to = (to); \ __cu_from = (from); \ __cu_len = (n); \ @@ -490,7 +489,7 @@ extern size_t __copy_user(void *__to, const void *__from, size_t __n); * @from: Source address, in user space. * @n: Number of bytes to copy. * - * Context: User context only. This function may sleep. + * Context: User context only. * * Copy data from user space to kernel space. Caller must check * the specified block with access_ok() before calling this function. @@ -507,7 +506,6 @@ extern size_t __copy_user(void *__to, const void *__from, size_t __n); const void __user *__cu_from; \ long __cu_len; \ \ - might_sleep(); \ __cu_to = (to); \ __cu_from = (from); \ __cu_len = (n); \ -- 1.4.4.3.ge6d4 From anemo@mba.ocn.ne.jp Fri Feb 16 15:44:50 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 15:44:56 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:10743 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038909AbXBPPou (ORCPT ); Fri, 16 Feb 2007 15:44:50 +0000 Received: from localhost (p2199-ipad213funabasi.chiba.ocn.ne.jp [124.85.67.199]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 8C5C6AAD4 for ; Sat, 17 Feb 2007 00:43:29 +0900 (JST) Date: Sat, 17 Feb 2007 00:43:29 +0900 (JST) Message-Id: <20070217.004329.108739438.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: fadvise on MIPS From: Atsushi Nemoto X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14120 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips I found some confusions about posix_fadvise() on MIPS. 1) unistd.h defines __NR_fadvise64 for all ABI but no __NR_fadvise64_64. But sys_fadvise64_64 is used for all syscall entries. For N64, sys_fadvise64 and sys_fadvise64_64 are same so no problem, but for other ABIs size of 'len' argument cause mismatch between kernel and libc. 2) On O32, glibc pass a 'long long' argument by hi and lo words, but kernel needs padding word between 'fd' and 'offset' argument. 3) On N32, glibc pass a 'long long' argument by hi and lo words, but kernel expects a single register value for 'long long' argument. 4) __ARCH_WANT_SYS_FADVISE64 is defined in unistd.h but sys_fadvise64 is not used. What is preferred way to fix those issues? It seems N64 do not need any fix. For N32 and O32, kernel should be fixed anyway, but which syscall should be supported? And whether kernel or libc should take care of 'long long' issue? --- Atsushi Nemoto From anemo@mba.ocn.ne.jp Fri Feb 16 15:49:31 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 15:49:36 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:52223 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038909AbXBPPtb (ORCPT ); Fri, 16 Feb 2007 15:49:31 +0000 Received: from localhost (p2199-ipad213funabasi.chiba.ocn.ne.jp [124.85.67.199]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 98A83BC41 for ; Sat, 17 Feb 2007 00:48:12 +0900 (JST) Date: Sat, 17 Feb 2007 00:48:12 +0900 (JST) Message-Id: <20070217.004812.03978264.anemo@mba.ocn.ne.jp> To: linux-mips@linux-mips.org Subject: Re: fadvise on MIPS From: Atsushi Nemoto In-Reply-To: <20070217.004329.108739438.anemo@mba.ocn.ne.jp> References: <20070217.004329.108739438.anemo@mba.ocn.ne.jp> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14121 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Sat, 17 Feb 2007 00:43:29 +0900 (JST), Atsushi Nemoto wrote: > 2) On O32, glibc pass a 'long long' argument by hi and lo words, but > kernel needs padding word between 'fd' and 'offset' argument. > > 3) On N32, glibc pass a 'long long' argument by hi and lo words, but > kernel expects a single register value for 'long long' argument. And sync_file_range() has some problem too. --- Atsushi Nemoto From ralf@linux-mips.org Fri Feb 16 15:54:42 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 15:54:44 +0000 (GMT) Received: from localhost.localdomain ([127.0.0.1]:12218 "EHLO dl5rb.ham-radio-op.net") by ftp.linux-mips.org with ESMTP id S20038999AbXBPPym (ORCPT ); Fri, 16 Feb 2007 15:54:42 +0000 Received: from denk.linux-mips.net (denk.linux-mips.net [127.0.0.1]) by dl5rb.ham-radio-op.net (8.13.8/8.13.8) with ESMTP id l1GFsgrL026896; Fri, 16 Feb 2007 15:54:42 GMT Received: (from ralf@localhost) by denk.linux-mips.net (8.13.8/8.13.8/Submit) id l1GFsg9k026895; Fri, 16 Feb 2007 15:54:42 GMT Date: Fri, 16 Feb 2007 15:54:42 +0000 From: Ralf Baechle To: Franck Bui-Huu Cc: linux-mips Subject: Re: [PATCH] Fix __copy_{to,from}_user_inatomic Message-ID: <20070216155441.GA26835@linux-mips.org> References: <45D5CEA5.3050604@innova-card.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <45D5CEA5.3050604@innova-card.com> User-Agent: Mutt/1.4.2.2i Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14122 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: ralf@linux-mips.org Precedence: bulk X-list: linux-mips On Fri, Feb 16, 2007 at 04:32:53PM +0100, Franck Bui-Huu wrote: > These functions are aliases to __copy_{to,from}_user resp but they > are not allowed to sleep. Therefore might_sleep() must not be used > by their implementions. The _inatomic functions are know to buggy but this doesn't quite fix the whole issues with them. On error __copy_from_user_inatomic should not clear the non-copied part of the destination buffer. See 01408c4939479ec46c15aa7ef6e2406be50eeeca and 7c12d81134b130ccd4c286b434ca48c4cda71a2f for the rationale. Ralf From vagabon.xyz@gmail.com Fri Feb 16 16:07:12 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 16:07:16 +0000 (GMT) Received: from qb-out-0506.google.com ([72.14.204.231]:52273 "EHLO qb-out-0506.google.com") by ftp.linux-mips.org with ESMTP id S20038909AbXBPQHM (ORCPT ); Fri, 16 Feb 2007 16:07:12 +0000 Received: by qb-out-0506.google.com with SMTP id e12so292206qba for ; Fri, 16 Feb 2007 08:06:11 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=ZmjNnemaBCFTZpLrUp/fJu3+mL+aeZuamwX9GbxG+5mnTc6wKgP1rJoUgc8aXWQ7HYUH+vwIx6ohb3GPSzNVHMtlUx/L+zr+mP95oGRpHA6pmBX16bo+rQd9lekyRkzdUYRQrbIOln69Inxo7LaiNgkMS6ranBJb/vbq0uAx9LA= Received: by 10.115.78.1 with SMTP id f1mr1831904wal.1171641970362; Fri, 16 Feb 2007 08:06:10 -0800 (PST) Received: by 10.114.136.11 with HTTP; Fri, 16 Feb 2007 08:06:10 -0800 (PST) Message-ID: Date: Fri, 16 Feb 2007 17:06:10 +0100 From: "Franck Bui-Huu" To: "Ralf Baechle" Subject: Re: [PATCH] Fix __copy_{to,from}_user_inatomic Cc: linux-mips In-Reply-To: <20070216155441.GA26835@linux-mips.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <45D5CEA5.3050604@innova-card.com> <20070216155441.GA26835@linux-mips.org> Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14123 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: vagabon.xyz@gmail.com Precedence: bulk X-list: linux-mips On 2/16/07, Ralf Baechle wrote: > On Fri, Feb 16, 2007 at 04:32:53PM +0100, Franck Bui-Huu wrote: > > > These functions are aliases to __copy_{to,from}_user resp but they > > are not allowed to sleep. Therefore might_sleep() must not be used > > by their implementions. > > The _inatomic functions are know to buggy but this doesn't quite fix the > whole issues with them. ok so the patch's should have been: "Fix console warnings triggered by __copy_{to,from}_user_inatomic()" > On error __copy_from_user_inatomic should not > clear the non-copied part of the destination buffer. See > 01408c4939479ec46c15aa7ef6e2406be50eeeca and > 7c12d81134b130ccd4c286b434ca48c4cda71a2f for the rationale. I'll try to take a look at it. Thanks -- Franck From anemo@mba.ocn.ne.jp Fri Feb 16 16:13:39 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 16:13:44 +0000 (GMT) Received: from mba.ocn.ne.jp ([210.190.142.172]:19676 "HELO smtp.mba.ocn.ne.jp") by ftp.linux-mips.org with SMTP id S20038953AbXBPQNj (ORCPT ); Fri, 16 Feb 2007 16:13:39 +0000 Received: from localhost (p2199-ipad213funabasi.chiba.ocn.ne.jp [124.85.67.199]) by smtp.mba.ocn.ne.jp (Postfix) with ESMTP id 6A27CA1F0; Sat, 17 Feb 2007 01:12:20 +0900 (JST) Date: Sat, 17 Feb 2007 01:12:20 +0900 (JST) Message-Id: <20070217.011220.70478485.anemo@mba.ocn.ne.jp> To: vagabon.xyz@gmail.com Cc: ralf@linux-mips.org, linux-mips@linux-mips.org Subject: Re: [PATCH] Fix __copy_{to,from}_user_inatomic From: Atsushi Nemoto In-Reply-To: <45D5CEA5.3050604@innova-card.com> References: <45D5CEA5.3050604@innova-card.com> X-Fingerprint: 6ACA 1623 39BD 9A94 9B1A B746 CA77 FE94 2874 D52F X-Pgp-Public-Key: http://wwwkeys.pgp.net/pks/lookup?op=get&search=0x2874D52F X-Mailer: Mew version 3.3 on Emacs 21.4 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14124 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: anemo@mba.ocn.ne.jp Precedence: bulk X-list: linux-mips On Fri, 16 Feb 2007 16:32:53 +0100, Franck Bui-Huu wrote: > These functions are aliases to __copy_{to,from}_user resp but they > are not allowed to sleep. Therefore might_sleep() must not be used > by their implementions. This changes CONFIG_PREEMPT_VOLUNTARY behavior. In this case might_sleep() is not just an annotation. Well, so currently CONFIG_PREEMPT_VOLUNTARY seems broken. Maybe we need separete functions anyway. --- Atsushi Nemoto From Marc_St-Jean@pmc-sierra.com Fri Feb 16 16:31:47 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 16:31:49 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:28598 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039048AbXBPQbr (ORCPT ); Fri, 16 Feb 2007 16:31:47 +0000 Received: (qmail 25663 invoked by uid 101); 16 Feb 2007 16:30:35 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by mother.pmc-sierra.com with SMTP; 16 Feb 2007 16:30:35 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1GGUYC8029448; Fri, 16 Feb 2007 08:30:34 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <17WPXC0Y>; Fri, 16 Feb 2007 08:30:34 -0800 Message-ID: <45D5DC24.7090506@pmc-sierra.com> From: Marc St-Jean To: Andrew Morton Cc: Marc St-Jean , linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Fri, 16 Feb 2007 08:30:28 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 16 Feb 2007 16:30:28.0716 (UTC) FILETIME=[C4F6EAC0:01C751E7] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14125 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Andrew Morton wrote: > On Thu, 15 Feb 2007 13:26:29 -0600 > Marc St-Jean wrote: > > > + status = *(volatile u32 *)up->port.private_data; > > It distresses me that this patch uses a variable which this patch > doesn't initialise anywhere. It isn't complete. > > The sub-driver code whch sets up this field shuld be included in the > patch, no? > OK, I'll re-post with the platform file which initializes the variable. That file however will reference other files in the platform which has not been posted yet. I thought it was better to post the driver-only code. Marc From Marc_St-Jean@pmc-sierra.com Fri Feb 16 17:08:05 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 17:08:07 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:61623 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20039085AbXBPRIF (ORCPT ); Fri, 16 Feb 2007 17:08:05 +0000 Received: (qmail 29516 invoked by uid 101); 16 Feb 2007 17:06:58 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by father.pmc-sierra.com with SMTP; 16 Feb 2007 17:06:58 -0000 Received: from bby1exi01.pmc_nt.nt.pmc-sierra.bc.ca (bby1exi01.pmc-sierra.bc.ca [216.241.231.251]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1GH6rHd031984; Fri, 16 Feb 2007 09:06:53 -0800 Received: by bby1exi01.pmc-sierra.bc.ca with Internet Mail Service (5.5.2657.72) id <17WPX1G5>; Fri, 16 Feb 2007 09:06:53 -0800 Message-ID: <45D5E4A7.3070807@pmc-sierra.com> From: Marc St-Jean To: Sergei Shtylyov Cc: Marc St-Jean , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er Date: Fri, 16 Feb 2007 09:06:47 -0800 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2657.72) x-originalarrivaltime: 16 Feb 2007 17:06:48.0341 (UTC) FILETIME=[D81F4C50:01C751EC] user-agent: Thunderbird 1.5.0.9 (X11/20061206) Content-Type: text/plain; charset="iso-8859-1" Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14126 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: Marc_St-Jean@pmc-sierra.com Precedence: bulk X-list: linux-mips Sergei Shtylyov wrote: > Hello. > > Marc St-Jean wrote: > > > There are three different fixes: > > 1. Fix for DesignWare APB THRE errata: > > In brief, this is a non-standard 16550 in that the THRE interrupt > > will not re-assert itself simply by disabling and re-enabling the > > THRI bit in the IER, it is only re-enabled if a character is actually > > sent out. > > It appears that the "8250-uart-backup-timer.patch" in the "mm" tree also > > fixes it so we have dropped our initial workaround. > > This patch now needs to be applied on top of that "mm" patch. > > This patch has hit the mainline kernel already. I see, I'll drop the reference to the "mm" patch. > > 3. Workaround for interrupt/data concurrency issue: > > The SoC needs to ensure that writes that can cause interrupts to be > > cleared reach the UART before returning from the ISR. This fix reads > > a non-destructive register on the UART so the read transaction > > completion ensures the previously queued write transaction has > > also completed. > > > The differences from the last attempt is dropping the call to > > in_irq() and including more detailed description of the fixes. > > The difference part would better be under the "---" cutoff line, along > with diffstat. > This way it gets auto-removed by quilt/git when applying the patch. I'll add to the next posting. > > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c > > index 3d91bfc..bfaacc5 100644 > > --- a/drivers/serial/8250.c > > +++ b/drivers/serial/8250.c > > @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar > > return inb(up->port.iobase + 1); > > > > case UPIO_MEM: > > + case UPIO_DWAPB: > > return readb(up->port.membase + offset); > > > > case UPIO_MEM32: > > @@ -333,6 +334,8 @@ #endif > > static void > > serial_out(struct uart_8250_port *up, int offset, int value) > > { > > + /* Save the offset before it's remapped */ > > + int save_offset = offset; > > offset = map_8250_out_reg(up, offset) << up->port.regshift; > > > > switch (up->port.iotype) { > > I've just got an idea how to "beautify" this code -- rename the > 'offset' > arg to something like reg, and then declare/init 'offset' as local > variable. > Would certainly look better (and worth doing in all serial_* accessros). I agree but am having enough of a hard time getting the bare minimum accepted that I don't dare touch any unnecessary lines. > > @@ -359,6 +362,18 @@ #endif > > writeb(value, up->port.membase + offset); > > break; > > > > + case UPIO_DWAPB: > > + /* Save the LCR value so it can be re-written when a > > + * Busy Detect interrupt occurs. */ > > + if (save_offset == UART_LCR) > > + up->lcr = value; > > + writeb(value, up->port.membase + offset); > > + /* Read the IER to ensure any interrupt is cleared before > > + * returning from ISR. */ > > + if (save_offset == UART_TX || save_offset == UART_IER) > > + value = serial_in(up, UART_IER); > > + break; > > + > > default: > > outb(value, up->port.iobase + offset); > > } > > @@ -2454,8 +2485,8 @@ int __init serial8250_start_console(stru > > > > add_preferred_console("ttyS", line, options); > > printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", > > - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", > > - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : > > + line, port->iotype >= UPIO_MEM ? "MMIO" : "I/O port", > > + port->iotype >= UPIO_MEM ? (unsigned long) port->mapbase : > > (unsigned long) port->iobase, options); > > if (!(serial8250_console.flags & CON_ENABLED)) { > > serial8250_console.flags &= ~CON_PRINTBUFFER; > > I've remembered why I decided not to fix it: this code only gets called > from 8250__eraly.c which can't handle anything beyond UPIO_MEM anyway. We don't use 8250_early and I've tested it works without, so I'll drop this change. Thanks, Marc From sshtylyov@ru.mvista.com Fri Feb 16 17:22:11 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 17:22:15 +0000 (GMT) Received: from h155.mvista.com ([63.81.120.155]:62668 "EHLO imap.sh.mvista.com") by ftp.linux-mips.org with ESMTP id S20039053AbXBPRWL (ORCPT ); Fri, 16 Feb 2007 17:22:11 +0000 Received: from [192.168.1.248] (unknown [10.150.0.9]) by imap.sh.mvista.com (Postfix) with ESMTP id 9A2593EC9; Fri, 16 Feb 2007 09:21:36 -0800 (PST) Message-ID: <45D5E81B.7030304@ru.mvista.com> Date: Fri, 16 Feb 2007 20:21:31 +0300 From: Sergei Shtylyov Organization: MontaVista Software Inc. User-Agent: Mozilla/5.0 (X11; U; Linux i686; rv:1.7.2) Gecko/20040803 X-Accept-Language: ru, en-us, en-gb MIME-Version: 1.0 To: Marc St-Jean Cc: Marc St-Jean , akpm@linux-foundation.org, linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Subject: Re: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git mast er References: <45D5E4A7.3070807@pmc-sierra.com> In-Reply-To: <45D5E4A7.3070807@pmc-sierra.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14127 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: sshtylyov@ru.mvista.com Precedence: bulk X-list: linux-mips Hello. Marc St-Jean wrote: >> > diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c >> > index 3d91bfc..bfaacc5 100644 >> > --- a/drivers/serial/8250.c >> > +++ b/drivers/serial/8250.c >> > @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar >> > return inb(up->port.iobase + 1); >> > >> > case UPIO_MEM: >> > + case UPIO_DWAPB: >> > return readb(up->port.membase + offset); >> > >> > case UPIO_MEM32: >> > @@ -333,6 +334,8 @@ #endif >> > static void >> > serial_out(struct uart_8250_port *up, int offset, int value) >> > { >> > + /* Save the offset before it's remapped */ >> > + int save_offset = offset; >> > offset = map_8250_out_reg(up, offset) << up->port.regshift; >> > >> > switch (up->port.iotype) { >> I've just got an idea how to "beautify" this code -- rename the >>'offset' >>arg to something like reg, and then declare/init 'offset' as local >>variable. >>Would certainly look better (and worth doing in all serial_* accessros). > I agree but am having enough of a hard time getting the bare minimum > accepted that I don't dare touch any unnecessary lines. Well, I can try pushing this simple cleanup myself... seems worth doing for alike future cases anyway. >> > @@ -359,6 +362,18 @@ #endif >> > writeb(value, up->port.membase + offset); >> > break; >> > >> > + case UPIO_DWAPB: >> > + /* Save the LCR value so it can be re-written when a >> > + * Busy Detect interrupt occurs. */ >> > + if (save_offset == UART_LCR) >> > + up->lcr = value; >> > + writeb(value, up->port.membase + offset); >> > + /* Read the IER to ensure any interrupt is cleared before >> > + * returning from ISR. */ >> > + if (save_offset == UART_TX || save_offset == UART_IER) >> > + value = serial_in(up, UART_IER); >> > + break; >> > + >> > default: >> > outb(value, up->port.iobase + offset); >> > } >> > @@ -2454,8 +2485,8 @@ int __init serial8250_start_console(stru >> > >> > add_preferred_console("ttyS", line, options); >> > printk("Adding console on ttyS%d at %s 0x%lx (options '%s')\n", >> > - line, port->iotype == UPIO_MEM ? "MMIO" : "I/O port", >> > - port->iotype == UPIO_MEM ? (unsigned long) port->mapbase : >> > + line, port->iotype >= UPIO_MEM ? "MMIO" : "I/O port", >> > + port->iotype >= UPIO_MEM ? (unsigned long) port->mapbase : >> > (unsigned long) port->iobase, options); >> > if (!(serial8250_console.flags & CON_ENABLED)) { >> > serial8250_console.flags &= ~CON_PRINTBUFFER; >> I've remembered why I decided not to fix it: this code only gets called >>from 8250__eraly.c which can't handle anything beyond UPIO_MEM anyway. > We don't use 8250_early and I've tested it works without, so I'll drop this > change. No need I guess since this is the Right Thing (TM) anyway. > Thanks, > Marc WBR, Sergei From stjeanma@pmc-sierra.com Fri Feb 16 17:40:41 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 17:40:46 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:47049 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S20038999AbXBPRkl (ORCPT ); Fri, 16 Feb 2007 17:40:41 +0000 Received: (qmail 16922 invoked by uid 101); 16 Feb 2007 17:39:34 -0000 Received: from unknown (HELO pmxedge1.pmc-sierra.bc.ca) (216.241.226.183) by mother.pmc-sierra.com with SMTP; 16 Feb 2007 17:39:34 -0000 Received: from pasqua.pmc-sierra.bc.ca (pasqua.pmc-sierra.bc.ca [134.87.183.161]) by pmxedge1.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1GHdX95024411; Fri, 16 Feb 2007 09:39:33 -0800 From: Marc St-Jean Received: (from stjeanma@localhost) by pasqua.pmc-sierra.bc.ca (8.13.4/8.12.11) id l1GHdIvZ021610; Fri, 16 Feb 2007 11:39:18 -0600 Date: Fri, 16 Feb 2007 11:39:18 -0600 Message-Id: <200702161739.l1GHdIvZ021610@pasqua.pmc-sierra.bc.ca> To: akpm@linux-foundation.org Subject: [PATCH] serial driver PMC MSP71xx, kernel linux-mips.git master Cc: linux-kernel@vger.kernel.org, linux-mips@linux-mips.org, linux-serial@vger.kernel.org Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14128 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stjeanma@pmc-sierra.com Precedence: bulk X-list: linux-mips Serial driver patch for the PMC-Sierra MSP71xx devices. There are three different fixes: 1. Fix for DesignWare APB THRE errata: In brief, this is a non-standard 16550 in that the THRE interrupt will not re-assert itself simply by disabling and re-enabling the THRI bit in the IER, it is only re-enabled if a character is actually sent out. It appears that the "8250-uart-backup-timer.patch" in the "mm" tree also fixes it so we have dropped our initial workaround. This patch now needs to be applied on top of that "mm" patch. 2. Fix for Busy Detect on LCR write: The DesignWare APB UART has a feature which causes a new Busy Detect interrupt to be generated if it's busy when the LCR is written. This fix saves the value of the LCR and rewrites it after clearing the interrupt. 3. Workaround for interrupt/data concurrency issue: The SoC needs to ensure that writes that can cause interrupts to be cleared reach the UART before returning from the ISR. This fix reads a non-destructive register on the UART so the read transaction completion ensures the previously queued write transaction has also completed. Thanks, Marc Signed-off-by: Marc St-Jean --- Try number eigth, changes since last patch: -Dropped fix to serial8250_start_console for port->iotype >= UPIO_MEM since we don't absolutely need this. -Added platform file initializing the serial ports to patch. arch/mips/pmc-sierra/msp71xx/msp_serial.c | 165 ++++++++++++++++++++++++++++++ drivers/serial/8250.c | 31 +++++ drivers/serial/8250.h | 0 drivers/serial/serial_core.c | 2 include/linux/serial_core.h | 2 include/linux/serial_reg.h | 2 6 files changed, 202 insertions(+) diff --git a/drivers/serial/8250.c b/drivers/serial/8250.c index 3d91bfc..d224c35 100644 --- a/drivers/serial/8250.c +++ b/drivers/serial/8250.c @@ -308,6 +308,7 @@ static unsigned int serial_in(struct uar return inb(up->port.iobase + 1); case UPIO_MEM: + case UPIO_DWAPB: return readb(up->port.membase + offset); case UPIO_MEM32: @@ -333,6 +334,8 @@ #endif static void serial_out(struct uart_8250_port *up, int offset, int value) { + /* Save the offset before it's remapped */ + int save_offset = offset; offset = map_8250_out_reg(up, offset) << up->port.regshift; switch (up->port.iotype) { @@ -359,6 +362,18 @@ #endif writeb(value, up->port.membase + offset); break; + case UPIO_DWAPB: + /* Save the LCR value so it can be re-written when a + * Busy Detect interrupt occurs. */ + if (save_offset == UART_LCR) + up->lcr = value; + writeb(value, up->port.membase + offset); + /* Read the IER to ensure any interrupt is cleared before + * returning from ISR. */ + if (save_offset == UART_TX || save_offset == UART_IER) + value = serial_in(up, UART_IER); + break; + default: outb(value, up->port.iobase + offset); } @@ -373,6 +388,7 @@ serial_out_sync(struct uart_8250_port *u #ifdef CONFIG_SERIAL_8250_AU1X00 case UPIO_AU: #endif + case UPIO_DWAPB: serial_out(up, offset, value); (void)serial_in(up, UART_LCR); /* safe, no side-effects */ break; @@ -1383,6 +1399,19 @@ static irqreturn_t serial8250_interrupt( handled = 1; end = NULL; + } else if (up->port.iotype == UPIO_DWAPB && + (iir & UART_IIR_BUSY) == UART_IIR_BUSY) { + /* The DesignWare APB UART has an Busy Detect (0x07) + * interrupt meaning an LCR write attempt occured while the + * UART was busy. The interrupt must be cleared by reading + * the UART status register (USR) and the LCR re-written. */ + unsigned int status; + status = *(volatile u32 *)up->port.private_data; + serial_out(up, UART_LCR, up->lcr); + + handled = 1; + + end = NULL; } else if (end == NULL) end = l; @@ -2085,6 +2114,7 @@ static int serial8250_request_std_resour case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; @@ -2122,6 +2152,7 @@ static void serial8250_release_std_resou case UPIO_TSI: case UPIO_MEM32: case UPIO_MEM: + case UPIO_DWAPB: if (!up->port.mapbase) break; diff --git a/drivers/serial/8250.h b/drivers/serial/8250.h diff --git a/drivers/serial/serial_core.c b/drivers/serial/serial_core.c index f84982e..f5b6036 100644 --- a/drivers/serial/serial_core.c +++ b/drivers/serial/serial_core.c @@ -2057,6 +2057,7 @@ uart_report_port(struct uart_driver *drv case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: snprintf(address, sizeof(address), "MMIO 0x%lx", port->mapbase); break; @@ -2401,6 +2402,7 @@ int uart_match_port(struct uart_port *po case UPIO_MEM32: case UPIO_AU: case UPIO_TSI: + case UPIO_DWAPB: return (port1->mapbase == port2->mapbase); } return 0; diff --git a/include/linux/serial_core.h b/include/linux/serial_core.h index cf23813..8cdd326 100644 --- a/include/linux/serial_core.h +++ b/include/linux/serial_core.h @@ -230,6 +230,7 @@ #define UPIO_MEM (2) #define UPIO_MEM32 (3) #define UPIO_AU (4) /* Au1x00 type IO */ #define UPIO_TSI (5) /* Tsi108/109 type IO */ +#define UPIO_DWAPB (6) /* DesignWare APB UART */ unsigned int read_status_mask; /* driver specific */ unsigned int ignore_status_mask; /* driver specific */ @@ -276,6 +277,7 @@ #define UPF_USR_MASK ((__force upf_t) ( struct device *dev; /* parent device */ unsigned char hub6; /* this should be in the 8250 driver */ unsigned char unused[3]; + void *private_data; /* generic platform data pointer */ }; /* diff --git a/include/linux/serial_reg.h b/include/linux/serial_reg.h index 3c8a6aa..1c5ed7d 100644 --- a/include/linux/serial_reg.h +++ b/include/linux/serial_reg.h @@ -38,6 +38,8 @@ #define UART_IIR_THRI 0x02 /* Transmitt #define UART_IIR_RDI 0x04 /* Receiver data interrupt */ #define UART_IIR_RLSI 0x06 /* Receiver line status interrupt */ +#define UART_IIR_BUSY 0x07 /* DesignWare APB Busy Detect */ + #define UART_FCR 2 /* Out: FIFO Control Register */ #define UART_FCR_ENABLE_FIFO 0x01 /* Enable the FIFO */ #define UART_FCR_CLEAR_RCVR 0x02 /* Clear the RCVR FIFO */ diff --git a/arch/mips/pmc-sierra/msp71xx/msp_serial.c b/arch/mips/pmc-sierra/msp71xx/msp_serial.c new file mode 100644 index 0000000..c1afa90 --- /dev/null +++ b/arch/mips/pmc-sierra/msp71xx/msp_serial.c @@ -0,0 +1,165 @@ +/* + * The setup file for serial related hardware on PMC-Sierra MSP processors. + * + * Copyright 2005 PMC-Sierra, Inc. + * + * This program is free software; you can redistribute it and/or modify it + * under the terms of the GNU General Public License as published by the + * Free Software Foundation; either version 2 of the License, or (at your + * option) any later version. + * + * THIS SOFTWARE IS PROVIDED ``AS IS'' AND ANY EXPRESS OR IMPLIED + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN + * NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, + * INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT + * NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF + * USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON + * ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT + * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF + * THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. + * + * You should have received a copy of the GNU General Public License along + * with this program; if not, write to the Free Software Foundation, Inc., + * 675 Mass Ave, Cambridge, MA 02139, USA. + */ + +#include +#include +#include + +#include +#include +#include +#include + +#include +#include +#include + +#ifdef CONFIG_KGDB +/* + * kgdb uses serial port 1 so the console can remain on port 0. + * To use port 0 change the definition to read as follows: + * #define DEBUG_PORT_BASE KSEG1ADDR(MSP_UART0_BASE) + */ +#define DEBUG_PORT_BASE KSEG1ADDR(MSP_UART1_BASE) + +int putDebugChar(char c) +{ + volatile uint32_t *uart = (volatile uint32_t *)DEBUG_PORT_BASE; + uint32_t val = (uint32_t)c; + + local_irq_disable(); + while( !(uart[5] & 0x20) ); /* Wait for TXRDY */ + uart[0] = val; + while( !(uart[5] & 0x20) ); /* Wait for TXRDY */ + local_irq_enable(); + + return 1; +} + +char getDebugChar(void) +{ + volatile uint32_t *uart = (volatile uint32_t *)DEBUG_PORT_BASE; + uint32_t val; + + while( !(uart[5] & 0x01) ); /* Wait for RXRDY */ + val = uart[0]; + + return (char)val; +} + +void initDebugPort(unsigned int uartclk, unsigned int baudrate) +{ + unsigned int baud_divisor = (uartclk + 8 * baudrate)/(16 * baudrate); + + /* Enable FIFOs */ + writeb(UART_FCR_ENABLE_FIFO | UART_FCR_CLEAR_RCVR | + UART_FCR_CLEAR_XMIT | UART_FCR_TRIGGER_4, + (char *)DEBUG_PORT_BASE + (UART_FCR * 4)); + + /* Select brtc divisor */ + writeb(UART_LCR_DLAB, (char *)DEBUG_PORT_BASE + (UART_LCR * 4)); + + /* Store divisor lsb */ + writeb(baud_divisor, (char *)DEBUG_PORT_BASE + (UART_TX * 4)); + + /* Store divisor msb */ + writeb(baud_divisor >> 8, (char *)DEBUG_PORT_BASE + (UART_IER * 4)); + + /* Set 8N1 mode */ + writeb(UART_LCR_WLEN8, (char *)DEBUG_PORT_BASE + (UART_LCR * 4)); + + /* Disable flow control */ + writeb(0, (char *)DEBUG_PORT_BASE + (UART_MCR * 4)); + + /* Disable receive interrupt(!) */ + writeb(0, (char *)DEBUG_PORT_BASE + (UART_IER * 4)); +} +#endif + +void __init msp_serial_setup(void) +{ + char *s; + char *endp; + struct uart_port up; + unsigned int uartclk; + + memset(&up, 0, sizeof(up)); + + /* Check if clock was specified in environment */ + s = prom_getenv("uartfreqhz"); + if(!(s && *s && (uartclk = simple_strtoul(s, &endp, 10)) && *endp == 0)) + uartclk = MSP_BASE_BAUD; + ppfinit("UART clock set to %d\n", uartclk); + + /* Initialize first serial port */ + up.mapbase = MSP_UART0_BASE; + up.membase = ioremap_nocache(up.mapbase,MSP_UART_REG_LEN); + up.irq = MSP_INT_UART0; + up.uartclk = uartclk; + up.regshift = 2; + up.iotype = UPIO_DWAPB; /* UPIO_MEM like */ + up.flags = STD_COM_FLAGS; + up.type = PORT_16550A; + up.line = 0; + up.private_data = (void*)UART0_STATUS_REG; + if (early_serial_setup(&up)) + printk(KERN_ERR "Early serial init of port 0 failed\n"); + + /* Initialize the second serial port, if one exists */ + switch (mips_machtype) { + case MACH_MSP4200_EVAL: + case MACH_MSP4200_GW: + case MACH_MSP4200_FPGA: + case MACH_MSP7120_EVAL: + case MACH_MSP7120_GW: + case MACH_MSP7120_FPGA: + /* Enable UART1 on MSP4200 and MSP7120 */ + *GPIO_CFG2_REG = 0x00002299; + +#ifdef CONFIG_KGDB + /* Initialize UART1 for kgdb since PMON doesn't */ + if( DEBUG_PORT_BASE == KSEG1ADDR(MSP_UART1_BASE) ) { + if( mips_machtype == MACH_MSP4200_FPGA + || mips_machtype == MACH_MSP7120_FPGA ) + initDebugPort(uartclk,19200); + else + initDebugPort(uartclk,57600); + } +#endif + break; + + default: + return; /* No second serial port, good-bye. */ + } + + up.mapbase = MSP_UART1_BASE; + up.membase = ioremap_nocache(up.mapbase,MSP_UART_REG_LEN); + up.irq = MSP_INT_UART1; + up.line = 1; + up.private_data = (void*)UART1_STATUS_REG; + if (early_serial_setup(&up)) + printk(KERN_ERR "Early serial init of port 1 failed\n"); +} From wilson@specifix.com Fri Feb 16 18:51:27 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 18:51:31 +0000 (GMT) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:42409 "EHLO bluesmobile.specifix.com") by ftp.linux-mips.org with ESMTP id S20039087AbXBPSv1 (ORCPT ); Fri, 16 Feb 2007 18:51:27 +0000 Received: from localhost.localdomain (bluesmobile.specifix.com [64.220.152.99]) by bluesmobile.specifix.com (Postfix) with ESMTP id 3C7A13B81F; Fri, 16 Feb 2007 10:50:40 -0800 (PST) Subject: Re: Who know latest Linux/MIPS ABI ? From: Jim Wilson To: =?UTF-8?Q?=EA=B9=80=EB=AF=BC=EC=B0=AC?= Cc: linux-mips@linux-mips.org In-Reply-To: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> References: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> Content-Type: text/plain; charset=utf-8 Date: Fri, 16 Feb 2007 10:50:46 -0800 Message-Id: <1171651846.2577.18.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 8bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14129 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Thu, 2007-02-15 at 10:46 +0900, 김민찬 wrote: > I hope I get a latest MIPS ABI and ELF Spec on Linux/MIPS. > Who know where I get it? There is some documentation available from SGI. Try http://docs.sgi.com You start by searching for ABI, but there may also be other docs you want to look at. There may also be relevant documentation available from MIPS. Try them also. http://www.mips.com and then hunt around for documentation. You can find good info on calling conventions in these places, but you aren't going to find good info on low level stuff like object file formats. For that, you will probably need to read code. You have two basic choices here. 1) Buy an SGI Irix5 and/or Irix6 machine, and start reading header files in /usr/include. Irix5 has ECOFF and ELF o32 support. Irix6 has ELF o32, n32, and n64 support. 2) Start reading the MIPS bfd support in GNU binutils. jcr is a gcc feature for java. Something like "java class record". It should be safe to ignore it unless you are using java. This isn't MIPS specific. pdr is procedure descriptor record. It is a left over from the SGI Irix5 ECOFF days, which SGI carried forward into their ELF implementation, and which was copied by the GNU and linux tools. For MIPS.stubs, that one I didn't know, I had to look it up. The bfd comments say it is for dynamic linking, so that function pointer comparisons work correctly for functions defined in shared libraries. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From wilson@specifix.com Fri Feb 16 19:02:15 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 19:02:19 +0000 (GMT) Received: from w099.z064220152.sjc-ca.dsl.cnc.net ([64.220.152.99]:45737 "EHLO bluesmobile.specifix.com") by ftp.linux-mips.org with ESMTP id S20039087AbXBPTCP (ORCPT ); Fri, 16 Feb 2007 19:02:15 +0000 Received: from localhost.localdomain (bluesmobile.specifix.com [64.220.152.99]) by bluesmobile.specifix.com (Postfix) with ESMTP id F31BB3B8BD; Fri, 16 Feb 2007 11:01:35 -0800 (PST) Subject: Re: Who know latest Linux/MIPS ABI ? From: Jim Wilson To: =?UTF-8?Q?=EA=B9=80=EB=AF=BC=EC=B0=AC?= Cc: linux-mips@linux-mips.org In-Reply-To: <1171651846.2577.18.camel@localhost.localdomain> References: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> <1171651846.2577.18.camel@localhost.localdomain> Content-Type: text/plain Date: Fri, 16 Feb 2007 11:01:42 -0800 Message-Id: <1171652502.2577.20.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.6.3 (2.6.3-1.fc5.5) Content-Transfer-Encoding: 7bit Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14130 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: wilson@specifix.com Precedence: bulk X-list: linux-mips On Fri, 2007-02-16 at 10:50 -0800, Jim Wilson wrote: > 1) Buy an SGI Irix5 and/or Irix6 machine, and start reading header files > in /usr/include. Irix5 has ECOFF and ELF o32 support. Irix6 has ELF > o32, n32, and n64 support. If you are desperate enough to try this, make sure the machine has a compiler. Some of the header files you need may be part of the compiler package, and I don't recall if the compiler comes standard with Irix. It might be an extra package. -- Jim Wilson, GNU Tools Support, http://www.specifix.com From reganrussell@optusnet.com.au Fri Feb 16 20:24:44 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 20:24:50 +0000 (GMT) Received: from mail30.syd.optusnet.com.au ([211.29.133.193]:57059 "EHLO mail30.syd.optusnet.com.au") by ftp.linux-mips.org with ESMTP id S28573781AbXBPUYo (ORCPT ); Fri, 16 Feb 2007 20:24:44 +0000 Received: from [10.10.0.102] (c211-31-24-26.belrs1.nsw.optusnet.com.au [211.31.24.26]) by mail30.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id l1GKNO3s008443; Sat, 17 Feb 2007 07:23:24 +1100 In-Reply-To: <1171652502.2577.20.camel@localhost.localdomain> References: <000701c750a3$24ecf9b0$8aab580a@swcenter.sec.samsung.co.kr> <1171651846.2577.18.camel@localhost.localdomain> <1171652502.2577.20.camel@localhost.localdomain> Mime-Version: 1.0 (Apple Message framework v752.2) Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: Cc: =?UTF-8?B?6rmA66+87LCs?= , linux-mips@linux-mips.org Content-Transfer-Encoding: 7bit From: regan Subject: Re: Who know latest Linux/MIPS ABI ? Date: Sat, 17 Feb 2007 07:27:49 +1100 To: Jim Wilson X-Mailer: Apple Mail (2.752.2) Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14131 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: reganrussell@optusnet.com.au Precedence: bulk X-list: linux-mips Hi, I am just joining this list. MIPS Pro compiler does not come free of charge. My initial quote from SGI was in the area of $3,000..! I have the latest compiler 7.4.4 i can have a look, when I get home. Regan On 2007/02/17, at 6:01, Jim Wilson wrote: > On Fri, 2007-02-16 at 10:50 -0800, Jim Wilson wrote: >> 1) Buy an SGI Irix5 and/or Irix6 machine, and start reading header >> files >> in /usr/include. Irix5 has ECOFF and ELF o32 support. Irix6 has ELF >> o32, n32, and n64 support. > > If you are desperate enough to try this, make sure the machine has a > compiler. Some of the header files you need may be part of the > compiler > package, and I don't recall if the compiler comes standard with Irix. > It might be an extra package. > -- > Jim Wilson, GNU Tools Support, http://www.specifix.com > > > From stjeanma@pmc-sierra.com Fri Feb 16 20:53:00 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 20:53:06 +0000 (GMT) Received: from mother.pmc-sierra.com ([216.241.224.12]:21896 "HELO mother.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S28573782AbXBPUxA (ORCPT ); Fri, 16 Feb 2007 20:53:00 +0000 Received: (qmail 16340 invoked by uid 101); 16 Feb 2007 20:51:43 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by mother.pmc-sierra.com with SMTP; 16 Feb 2007 20:51:43 -0000 Received: from pasqua.pmc-sierra.bc.ca (pasqua.pmc-sierra.bc.ca [134.87.183.161]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1GKpgbQ019090 for ; Fri, 16 Feb 2007 12:51:43 -0800 From: Marc St-Jean Received: (from stjeanma@localhost) by pasqua.pmc-sierra.bc.ca (8.13.4/8.12.11) id l1GKpcEM002083 for linux-mips@linux-mips.org; Fri, 16 Feb 2007 14:51:38 -0600 Date: Fri, 16 Feb 2007 14:51:38 -0600 Message-Id: <200702162051.l1GKpcEM002083@pasqua.pmc-sierra.bc.ca> To: linux-mips@linux-mips.org Subject: [PATCH 1/2] PMC MSP71xx platform patch, kernel linux-mips.git master Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14132 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stjeanma@pmc-sierra.com Precedence: bulk X-list: linux-mips [PATCH X/Y] NNNNNN PMC MSP71xx, kernel linux-mips.git master NNNNNN patch for the PMC-Sierra MSP71xx devices. Changes include: Thanks, Marc Signed-off-by: Marc St-Jean --- arch/mips/Kconfig | 81 + arch/mips/Makefile | 8 arch/mips/configs/msp71xx_defconfig | 1462 ++++++++++++++++++++++++++++++++++++ arch/mips/kernel/head.S | 8 arch/mips/kernel/traps.c | 19 include/asm-mips/bootinfo.h | 12 include/asm-mips/mipsregs.h | 30 include/asm-mips/war.h | 11 8 files changed, 1624 insertions(+), 7 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index da26de5..c8a1eb9 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -491,6 +491,24 @@ config MACH_VR41XX select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select GENERIC_HARDIRQS_NO__DO_IRQ +config PMC_MSP + bool "PMC-Sierra MSP chipsets" + depends on EXPERIMENTAL + select DMA_NONCOHERENT + select SWAP_IO_SPACE + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + select IRQ_CPU + select SERIAL_8250 + select SERIAL_8250_CONSOLE + help + This adds support for the PMC-Sierra family of Multi-Service + Processor System-On-A-Chips. These parts include a number + of integrated peripherals, interfaces and DSPs in addition to + a variety of MIPS cores. + config PMC_YOSEMITE bool "PMC-Sierra Yosemite eval board" select DMA_COHERENT @@ -807,6 +825,59 @@ config KEXEC support. As of this writing the exact hardware interface is strongly in flux, so no good recommendation can be made. +choice + prompt "PMC-Sierra MSP SOC type" + depends on PMC_MSP + +config PMC_MSP4200_EVAL + bool "PMC-Sierra MSP4200 Eval Board" + select IRQ_MSP_SLP + select HW_HAS_PCI + +config PMC_MSP4200_GW + bool "PMC-Sierra MSP4200 VoIP Gateway" + select IRQ_MSP_SLP + select HW_HAS_PCI + +config PMC_MSP7120_EVAL + bool "PMC-Sierra MSP7120 Eval Board" + select SYS_SUPPORTS_MULTITHREADING + select IRQ_MSP_CIC + select HW_HAS_PCI + select MSP_USB + +config PMC_MSP7120_GW + bool "PMC-Sierra MSP7120 Residential Gateway" + select SYS_SUPPORTS_MULTITHREADING + select IRQ_MSP_CIC + select HW_HAS_PCI + select MSP_USB + +config PMC_MSP7120_FPGA + bool "PMC-Sierra MSP7120 FPGA" + select SYS_SUPPORTS_MULTITHREADING + select IRQ_MSP_CIC + select HW_HAS_PCI + select MSP_USB + +endchoice + +menu "Options for PMC-Sierra MSP chipsets" + depends on PMC_MSP + +config PMC_MSP_EMBEDDED_ROOTFS + bool "Root filesystem embedded in kernel image" + select MTD + select MTD_BLOCK + select MTD_PMC_MSP_RAMROOT + select MTD_RAM + +config PMC_MSP_UNCACHED + bool "Run uncached" + select MIPS_UNCACHED + +endmenu + source "arch/mips/ddb5xxx/Kconfig" source "arch/mips/gt64120/ev64120/Kconfig" source "arch/mips/jazz/Kconfig" @@ -963,6 +1034,15 @@ config IRQ_CPU_RM9K config IRQ_MV64340 bool +config IRQ_MSP_SLP + bool + +config IRQ_MSP_CIC + bool + +config MSP_USB + bool + config DDB5XXX_COMMON bool @@ -1074,6 +1154,7 @@ config MIPS_L1_CACHE_SHIFT int default "4" if MACH_DECSTATION default "7" if SGI_IP27 + default "4" if PMC_MSP4200_EVAL default "5" config HAVE_STD_PC_SERIAL_PORT diff --git a/arch/mips/Makefile b/arch/mips/Makefile index d1b026a..02bae07 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -365,6 +365,14 @@ cflags-$(CONFIG_PMC_YOSEMITE) += -Iinclu load-$(CONFIG_PMC_YOSEMITE) += 0xffffffff80100000 # +# PMC-Sierra MSP SOCs +# +core-$(CONFIG_PMC_MSP) += arch/mips/pmc-sierra/msp71xx/ +cflags-$(CONFIG_PMC_MSP) += -Iinclude/asm-mips/pmc-sierra/msp71xx \ + -mno-branch-likely +load-$(CONFIG_PMC_MSP) += 0xffffffff80100000 + +# # Qemu simulating MIPS32 4Kc # core-$(CONFIG_QEMU) += arch/mips/qemu/ diff --git a/arch/mips/configs/msp71xx_defconfig b/arch/mips/configs/msp71xx_defconfig new file mode 100644 index 0000000..d336490 --- /dev/null +++ b/arch/mips/configs/msp71xx_defconfig @@ -0,0 +1,1462 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.20-rc5 +# Wed Feb 14 17:11:05 2007 +# +CONFIG_MIPS=y + +# +# Machine selection +# +# CONFIG_MIPS_MTX1 is not set +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_BASLER_EXCITE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_WR_PPMC is not set +# CONFIG_MIPS_SIM is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MIPS_XXS1500 is not set +# CONFIG_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +# CONFIG_PNX8550_STB810 is not set +# CONFIG_DDB5477 is not set +# CONFIG_MACH_VR41XX is not set +CONFIG_PMC_MSP=y +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_MARKEINS is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_BIGSUR is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SNI_RM is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +# CONFIG_KEXEC is not set +# CONFIG_PMC_MSP4200_EVAL is not set +# CONFIG_PMC_MSP4200_GW is not set +# CONFIG_PMC_MSP7120_EVAL is not set +CONFIG_PMC_MSP7120_GW=y +# CONFIG_PMC_MSP7120_FPGA is not set + +# +# Options for PMC-Sierra MSP chipsets +# +CONFIG_PMC_MSP_EMBEDDED_ROOTFS=y +# CONFIG_PMC_MSP_UNCACHED is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_FIND_NEXT_BIT=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_TIME=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +CONFIG_CPU_BIG_ENDIAN=y +# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y +CONFIG_IRQ_CPU=y +CONFIG_IRQ_MSP_CIC=y +CONFIG_MSP_USB=y +CONFIG_SWAP_IO_SPACE=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +# CONFIG_CPU_MIPS32_R1 is not set +CONFIG_CPU_MIPS32_R2=y +# CONFIG_CPU_MIPS64_R1 is not set +# CONFIG_CPU_MIPS64_R2 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_RM9000 is not set +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_SYS_HAS_CPU_MIPS32_R2=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPSR2=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_32BIT=y +# CONFIG_64BIT is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_MIPS_MT_DISABLED=y +# CONFIG_MIPS_MT_SMP is not set +# CONFIG_MIPS_MT_SMTC is not set +# CONFIG_MIPS_VPE_LOADER is not set +CONFIG_SYS_SUPPORTS_MULTITHREADING=y +# CONFIG_64BIT_PHYS_ADDR is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_RESOURCES_64BIT is not set +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=250 +# CONFIG_PREEMPT_NONE is not set +# CONFIG_PREEMPT_VOLUNTARY is not set +CONFIG_PREEMPT=y +# CONFIG_PREEMPT_BKL is not set +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="-pmc" +CONFIG_LOCALVERSION_AUTO=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +# CONFIG_IPC_NS is not set +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_UTS_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +# CONFIG_SHMEM is not set +CONFIG_SLAB=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_RT_MUTEXES=y +CONFIG_TINY_SHMEM=y +CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Block layer +# +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_PCI_DEBUG is not set +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# +# CONFIG_HOTPLUG_PCI is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_NETDEBUG is not set +# CONFIG_PACKET is not set +CONFIG_UNIX=y +CONFIG_XFRM=y +CONFIG_XFRM_USER=y +# CONFIG_XFRM_SUB_POLICY is not set +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set +# CONFIG_SYN_COOKIES is not set +CONFIG_INET_AH=y +CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y +CONFIG_INET_XFRM_TUNNEL=y +CONFIG_INET_TUNNEL=y +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_TCP_MD5SIG is not set + +# +# IP: Virtual Server Configuration +# +# CONFIG_IP_VS is not set +# CONFIG_IPV6 is not set +# CONFIG_INET6_XFRM_TUNNEL is not set +# CONFIG_INET6_TUNNEL is not set +# CONFIG_NETWORK_SECMARK is not set +CONFIG_NETFILTER=y +# CONFIG_NETFILTER_DEBUG is not set +CONFIG_BRIDGE_NETFILTER=y + +# +# Core Netfilter Configuration +# +# CONFIG_NETFILTER_NETLINK is not set +# CONFIG_NF_CONNTRACK_ENABLED is not set +CONFIG_NETFILTER_XTABLES=y +# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set +# CONFIG_NETFILTER_XT_TARGET_MARK is not set +# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set +# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set +# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set +# CONFIG_NETFILTER_XT_MATCH_DCCP is not set +# CONFIG_NETFILTER_XT_MATCH_DSCP is not set +# CONFIG_NETFILTER_XT_MATCH_ESP is not set +# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set +# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set +# CONFIG_NETFILTER_XT_MATCH_MAC is not set +# CONFIG_NETFILTER_XT_MATCH_MARK is not set +# CONFIG_NETFILTER_XT_MATCH_POLICY is not set +# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set +# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set +# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set +# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set +# CONFIG_NETFILTER_XT_MATCH_REALM is not set +# CONFIG_NETFILTER_XT_MATCH_SCTP is not set +# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set +# CONFIG_NETFILTER_XT_MATCH_STRING is not set +# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set +# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set + +# +# IP: Netfilter Configuration +# +# CONFIG_IP_NF_QUEUE is not set +CONFIG_IP_NF_IPTABLES=y +# CONFIG_IP_NF_MATCH_IPRANGE is not set +# CONFIG_IP_NF_MATCH_TOS is not set +# CONFIG_IP_NF_MATCH_RECENT is not set +# CONFIG_IP_NF_MATCH_ECN is not set +# CONFIG_IP_NF_MATCH_AH is not set +# CONFIG_IP_NF_MATCH_TTL is not set +# CONFIG_IP_NF_MATCH_OWNER is not set +# CONFIG_IP_NF_MATCH_ADDRTYPE is not set +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +# CONFIG_IP_NF_TARGET_LOG is not set +# CONFIG_IP_NF_TARGET_ULOG is not set +# CONFIG_IP_NF_TARGET_TCPMSS is not set +# CONFIG_IP_NF_MANGLE is not set +# CONFIG_IP_NF_RAW is not set +# CONFIG_IP_NF_ARPTABLES is not set + +# +# Bridge: Netfilter Configuration +# +# CONFIG_BRIDGE_NF_EBTABLES is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +CONFIG_BRIDGE=y +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +CONFIG_LLC=y +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set +CONFIG_WIRELESS_EXT=y + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FW_LOADER is not set +# CONFIG_DEBUG_DRIVER is not set +# CONFIG_SYS_HYPERVISOR is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set + +# +# Memory Technology Devices (MTD) +# +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set + +# +# RAM/ROM/Flash chip drivers +# +CONFIG_MTD_CFI=y +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_GEN_PROBE=y +# CONFIG_MTD_CFI_ADV_OPTIONS is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_CFI_INTELEXT is not set +CONFIG_MTD_CFI_AMDSTD=y +# CONFIG_MTD_CFI_STAA is not set +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_RAM=y +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set +# CONFIG_MTD_OBSOLETE_CHIPS is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PHYSMAP is not set +CONFIG_MTD_PMC_MSP_EVM=y +CONFIG_MSP_FLASH_MAP_LIMIT_32M=y +CONFIG_MSP_FLASH_MAP_LIMIT=0x02000000 +CONFIG_MTD_PMC_MSP_RAMROOT=y +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_PMC551 is not set +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +CONFIG_MTD_MTDRAM=y +CONFIG_MTDRAM_TOTAL_SIZE=0 +CONFIG_MTDRAM_ERASE_SIZE=0 +CONFIG_MTDRAM_ABS_POS=0 +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set + +# +# OneNAND Flash Device Drivers +# +# CONFIG_MTD_ONENAND is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=4096 +CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 +# CONFIG_BLK_DEV_INITRD is not set +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# Misc devices +# +# CONFIG_SGI_IOC4 is not set +# CONFIG_TIFM_CORE is not set + +# +# ATA/ATAPI/MFM/RLL support +# +# CONFIG_IDE is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=y +# CONFIG_SCSI_TGT is not set +# CONFIG_SCSI_NETLINK is not set +CONFIG_SCSI_PROC_FS=y + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set +# CONFIG_CHR_DEV_SCH is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set +# CONFIG_SCSI_SCAN_ASYNC is not set + +# +# SCSI Transports +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SAS_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set + +# +# SCSI low-level drivers +# +# CONFIG_ISCSI_TCP is not set +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_AIC94XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ARCMSR is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_MEGARAID_SAS is not set +# CONFIG_SCSI_HPTIOP is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_STEX is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +# CONFIG_SCSI_QLA_FC is not set +# CONFIG_SCSI_QLA_ISCSI is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set +# CONFIG_SCSI_DEBUG is not set +# CONFIG_SCSI_SRP is not set + +# +# Serial ATA (prod) and Parallel ATA (experimental) drivers +# +# CONFIG_ATA is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set +# CONFIG_FUSION_SPI is not set +# CONFIG_FUSION_FC is not set +# CONFIG_FUSION_SAS is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y +CONFIG_DUMMY=y +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# PHY device support +# +# CONFIG_PHYLIB is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_PMC_MSP_ETH is not set +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_DM9000 is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +# CONFIG_NET_PCI is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SKY2 is not set +# CONFIG_SK98LIN is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set +# CONFIG_QLA3XXX is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_CHELSIO_T1 is not set +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set +# CONFIG_MYRI10GE is not set +# CONFIG_NETXEN_NIC is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +CONFIG_NET_RADIO=y +# CONFIG_NET_WIRELESS_RTNETLINK is not set + +# +# Obsolete Wireless cards support (pre-802.11) +# +# CONFIG_STRIP is not set + +# +# Wireless 802.11b ISA/PCI cards support +# +# CONFIG_IPW2100 is not set +# CONFIG_IPW2200 is not set +# CONFIG_HERMES is not set +# CONFIG_ATMEL is not set + +# +# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support +# +# CONFIG_PRISM54 is not set +# CONFIG_USB_ZD1201 is not set +# CONFIG_HOSTAP is not set +CONFIG_NET_WIRELESS=y + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +CONFIG_PPP=y +# CONFIG_PPP_MULTILINK is not set +# CONFIG_PPP_FILTER is not set +# CONFIG_PPP_ASYNC is not set +# CONFIG_PPP_SYNC_TTY is not set +# CONFIG_PPP_DEFLATE is not set +# CONFIG_PPP_BSDCOMP is not set +# CONFIG_PPP_MPPE is not set +# CONFIG_PPPOE is not set +# CONFIG_SLIP is not set +CONFIG_SLHC=y +# CONFIG_NET_FC is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +CONFIG_INPUT=y +# CONFIG_INPUT_FF_MEMLESS is not set + +# +# Userland interfaces +# +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_TSDEV is not set +# CONFIG_INPUT_EVDEV is not set +# CONFIG_INPUT_EVBUG is not set + +# +# Input Device Drivers +# +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set + +# +# Hardware I/O ports +# +# CONFIG_SERIO is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +# CONFIG_VT is not set +# CONFIG_SERIAL_NONSTANDARD is not set +CONFIG_PMCMSP_GPIO=y + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +# CONFIG_SERIAL_8250_PCI is not set +CONFIG_SERIAL_8250_NR_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +# CONFIG_LEGACY_PTYS is not set + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +# CONFIG_HW_RANDOM is not set +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set + +# +# I2C support +# +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y + +# +# I2C Algorithms +# +# CONFIG_I2C_ALGOBIT is not set +# CONFIG_I2C_ALGOPCF is not set +# CONFIG_I2C_ALGOPCA is not set + +# +# I2C Hardware Bus support +# +# CONFIG_I2C_ALI1535 is not set +# CONFIG_I2C_ALI1563 is not set +# CONFIG_I2C_ALI15X3 is not set +# CONFIG_I2C_AMD756 is not set +# CONFIG_I2C_AMD8111 is not set +# CONFIG_I2C_I801 is not set +# CONFIG_I2C_I810 is not set +# CONFIG_I2C_PIIX4 is not set +# CONFIG_I2C_NFORCE2 is not set +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_PROSAVAGE is not set +# CONFIG_I2C_SAVAGE4 is not set +# CONFIG_I2C_SIS5595 is not set +# CONFIG_I2C_SIS630 is not set +# CONFIG_I2C_SIS96X is not set +# CONFIG_I2C_STUB is not set +# CONFIG_I2C_VIA is not set +# CONFIG_I2C_VIAPRO is not set +# CONFIG_I2C_VOODOO3 is not set +# CONFIG_I2C_PCA_ISA is not set + +# +# Miscellaneous I2C Chip support +# +# CONFIG_SENSORS_DS1337 is not set +# CONFIG_SENSORS_DS1374 is not set +# CONFIG_SENSORS_EEPROM is not set +# CONFIG_SENSORS_PCF8574 is not set +# CONFIG_SENSORS_PCA9539 is not set +# CONFIG_SENSORS_PCF8591 is not set +# CONFIG_SENSORS_MAX6875 is not set +# CONFIG_I2C_DEBUG_CORE is not set +# CONFIG_I2C_DEBUG_ALGO is not set +# CONFIG_I2C_DEBUG_BUS is not set +# CONFIG_I2C_DEBUG_CHIP is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +CONFIG_HWMON=y +# CONFIG_HWMON_VID is not set +# CONFIG_SENSORS_ABITUGURU is not set +# CONFIG_SENSORS_ADM1021 is not set +# CONFIG_SENSORS_ADM1025 is not set +# CONFIG_SENSORS_ADM1026 is not set +# CONFIG_SENSORS_ADM1031 is not set +# CONFIG_SENSORS_ADM9240 is not set +# CONFIG_SENSORS_ASB100 is not set +# CONFIG_SENSORS_ATXP1 is not set +# CONFIG_SENSORS_DS1621 is not set +# CONFIG_SENSORS_F71805F is not set +# CONFIG_SENSORS_FSCHER is not set +# CONFIG_SENSORS_FSCPOS is not set +# CONFIG_SENSORS_GL518SM is not set +# CONFIG_SENSORS_GL520SM is not set +# CONFIG_SENSORS_IT87 is not set +# CONFIG_SENSORS_LM63 is not set +# CONFIG_SENSORS_LM75 is not set +# CONFIG_SENSORS_LM77 is not set +# CONFIG_SENSORS_LM78 is not set +# CONFIG_SENSORS_LM80 is not set +# CONFIG_SENSORS_LM83 is not set +# CONFIG_SENSORS_LM85 is not set +# CONFIG_SENSORS_LM87 is not set +# CONFIG_SENSORS_LM90 is not set +# CONFIG_SENSORS_LM92 is not set +# CONFIG_SENSORS_MAX1619 is not set +# CONFIG_SENSORS_PC87360 is not set +# CONFIG_SENSORS_PC87427 is not set +# CONFIG_SENSORS_SIS5595 is not set +# CONFIG_SENSORS_SMSC47M1 is not set +# CONFIG_SENSORS_SMSC47M192 is not set +# CONFIG_SENSORS_SMSC47B397 is not set +# CONFIG_SENSORS_VIA686A is not set +# CONFIG_SENSORS_VT1211 is not set +# CONFIG_SENSORS_VT8231 is not set +# CONFIG_SENSORS_W83781D is not set +# CONFIG_SENSORS_W83791D is not set +# CONFIG_SENSORS_W83792D is not set +# CONFIG_SENSORS_W83793 is not set +# CONFIG_SENSORS_W83L785TS is not set +# CONFIG_SENSORS_W83627HF is not set +# CONFIG_SENSORS_W83627EHF is not set +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set +# CONFIG_USB_DABUSB is not set + +# +# Graphics support +# +# CONFIG_FIRMWARE_EDID is not set +# CONFIG_FB is not set +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# HID Devices +# +CONFIG_HID=y + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB_ARCH_HAS_EHCI=y +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_MULTITHREAD_PROBE is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_EHCI_SPLIT_ISO is not set +CONFIG_USB_EHCI_ROOT_HUB_TT=y +# CONFIG_USB_EHCI_TT_NEWSCHED is not set +# CONFIG_USB_ISP116X_HCD is not set +# CONFIG_USB_OHCI_HCD is not set +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=y +# CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_DATAFAB is not set +# CONFIG_USB_STORAGE_FREECOM is not set +# CONFIG_USB_STORAGE_DPCM is not set +# CONFIG_USB_STORAGE_USBAT is not set +# CONFIG_USB_STORAGE_SDDR09 is not set +# CONFIG_USB_STORAGE_SDDR55 is not set +# CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set +# CONFIG_USB_STORAGE_KARMA is not set +# CONFIG_USB_LIBUSUAL is not set + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# CONFIG_USB_KBD is not set +# CONFIG_USB_MOUSE is not set +# CONFIG_USB_AIPTEK is not set +# CONFIG_USB_WACOM is not set +# CONFIG_USB_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_TOUCHSCREEN is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET_MII is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_ADUTUX is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYPRESS_CY7C63 is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGET is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_FTDI_ELAN is not set +# CONFIG_USB_APPLEDISPLAY is not set +# CONFIG_USB_SISUSBVGA is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TRANCEVIBRATOR is not set +# CONFIG_USB_TEST is not set + +# +# USB DSL modem support +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# LED devices +# +# CONFIG_NEW_LEDS is not set + +# +# LED drivers +# + +# +# LED Triggers +# + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# EDAC - error detection and reporting (RAS) (EXPERIMENTAL) +# + +# +# Real Time Clock +# +# CONFIG_RTC_CLASS is not set + +# +# DMA Engine support +# +# CONFIG_DMA_ENGINE is not set + +# +# DMA Clients +# + +# +# DMA Devices +# + +# +# Virtualization +# + +# +# File systems +# +CONFIG_EXT2_FS=y +# CONFIG_EXT2_FS_XATTR is not set +# CONFIG_EXT2_FS_XIP is not set +# CONFIG_EXT3_FS is not set +# CONFIG_EXT4DEV_FS is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_GFS2_FS is not set +# CONFIG_OCFS2_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +# CONFIG_INOTIFY is not set +# CONFIG_QUOTA is not set +# CONFIG_DNOTIFY is not set +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +# CONFIG_PROC_KCORE is not set +CONFIG_PROC_SYSCTL=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_TMPFS_POSIX_ACL is not set +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_CONFIGFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +# CONFIG_JFFS2_SUMMARY is not set +# CONFIG_JFFS2_FS_XATTR is not set +# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set +# CONFIG_CRAMFS is not set +CONFIG_SQUASHFS=y +CONFIG_SQUASHFS_EMBEDDED=y +CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 +CONFIG_SQUASHFS_VMALLOC=y +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +# CONFIG_NFS_FS is not set +# CONFIG_NFSD is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="iso8859-1" +CONFIG_NLS_CODEPAGE_437=y +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +# CONFIG_NLS_ASCII is not set +CONFIG_NLS_ISO8859_1=y +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_UTF8 is not set + +# +# Distributed Lock Manager +# +# CONFIG_DLM is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +# CONFIG_PRINTK_TIME is not set +CONFIG_ENABLE_MUST_CHECK=y +CONFIG_MAGIC_SYSRQ=y +# CONFIG_UNUSED_SYMBOLS is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_HEADERS_CHECK is not set +CONFIG_DEBUG_KERNEL=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_DETECT_SOFTLOCKUP=y +# CONFIG_SCHEDSTATS is not set +# CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_PREEMPT=y +# CONFIG_DEBUG_RT_MUTEXES is not set +# CONFIG_RT_MUTEX_TESTER is not set +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_MUTEXES is not set +# CONFIG_DEBUG_RWSEMS is not set +# CONFIG_DEBUG_LOCK_ALLOC is not set +# CONFIG_PROVE_LOCKING is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set +# CONFIG_DEBUG_KOBJECT is not set +# CONFIG_DEBUG_INFO is not set +# CONFIG_DEBUG_VM is not set +# CONFIG_DEBUG_LIST is not set +CONFIG_FORCED_INLINING=y +# CONFIG_RCU_TORTURE_TEST is not set +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="" +# CONFIG_DEBUG_STACK_USAGE is not set +# CONFIG_KGDB is not set +# CONFIG_RUNTIME_DEBUG is not set +# CONFIG_MIPS_UNCACHED is not set + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_HMAC=y +# CONFIG_CRYPTO_XCBC is not set +CONFIG_CRYPTO_NULL=y +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_SHA1=y +# CONFIG_CRYPTO_SHA256 is not set +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_WP512 is not set +# CONFIG_CRYPTO_TGR192 is not set +# CONFIG_CRYPTO_GF128MUL is not set +CONFIG_CRYPTO_ECB=m +CONFIG_CRYPTO_CBC=y +# CONFIG_CRYPTO_LRW is not set +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_TWOFISH is not set +# CONFIG_CRYPTO_SERPENT is not set +CONFIG_CRYPTO_AES=y +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_ANUBIS is not set +CONFIG_CRYPTO_DEFLATE=y +# CONFIG_CRYPTO_MICHAEL_MIC is not set +# CONFIG_CRYPTO_CRC32C is not set +# CONFIG_CRYPTO_TEST is not set + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_BITREVERSE=y +# CONFIG_CRC_CCITT is not set +# CONFIG_CRC16 is not set +CONFIG_CRC32=y +# CONFIG_LIBCRC32C is not set +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y +CONFIG_PLIST=y +CONFIG_IOMAP_COPY=y diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S index 9a7811d..f9f5551 100644 --- a/arch/mips/kernel/head.S +++ b/arch/mips/kernel/head.S @@ -130,10 +130,18 @@ #endif .endm /* + * Reserverd space not required for PMC boards, although we need to + * jump to kernel start. + */ +#ifdef CONFIG_PMC_MSP + jal kernel_entry +#else + /* * Reserved space for exception handlers. * Necessary for machines which link their kernels at KSEG0. */ .fill 0x400 +#endif /* CONFIG_PMC_MSP */ EXPORT(stext) # used for profiling EXPORT(_stext) diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 2a932ca..e15a454 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -70,6 +70,7 @@ extern asmlinkage void handle_reserved(v extern int fpu_emulator_cop1Handler(struct pt_regs *xcp, struct mips_fpu_struct *ctx, int has_fpu); +void (*board_watchpoint_handler)(struct pt_regs *regs); void (*board_be_init)(void); int (*board_be_handler)(struct pt_regs *regs, int is_fixup); void (*board_nmi_handler_setup)(void); @@ -859,13 +860,17 @@ asmlinkage void do_mdmx(struct pt_regs * asmlinkage void do_watch(struct pt_regs *regs) { - /* - * We use the watch exception where available to detect stack - * overflows. - */ - dump_tlb_all(); - show_regs(regs); - panic("Caught WATCH exception - probably caused by stack overflow."); + if (board_watchpoint_handler) { + (*board_watchpoint_handler)(regs); + } else { + /* + * We use the watch exception where available to detect stack + * overflows. + */ + dump_tlb_all(); + show_regs(regs); + panic("Caught WATCH exception - probably caused by stack overflow."); + } } asmlinkage void do_mcheck(struct pt_regs *regs) diff --git a/include/asm-mips/bootinfo.h b/include/asm-mips/bootinfo.h index 8e321f5..6d27916 100644 --- a/include/asm-mips/bootinfo.h +++ b/include/asm-mips/bootinfo.h @@ -213,6 +213,18 @@ #define MACH_TITAN_EXCITE 2 /* Basler e #define MACH_GROUP_NEC_EMMA2RH 25 /* NEC EMMA2RH (was 23) */ #define MACH_NEC_MARKEINS 0 /* NEC EMMA2RH Mark-eins */ +/* + * Valid machtype for group PMC-MSP + */ +#define MACH_GROUP_MSP 23 /* PMC-Sierra MSP boards/CPUs */ +#define MACH_MSP4200_EVAL 0 /* PMC-Sierra MSP4200 Evaluation board */ +#define MACH_MSP4200_GW 1 /* PMC-Sierra MSP4200 Gateway demo board */ +#define MACH_MSP4200_FPGA 2 /* PMC-Sierra MSP4200 Emulation board */ +#define MACH_MSP7120_EVAL 3 /* PMC-Sierra MSP7120 Evaluation board */ +#define MACH_MSP7120_GW 4 /* PMC-Sierra MSP7120 Residential Gateway board */ +#define MACH_MSP7120_FPGA 5 /* PMC-Sierra MSP7120 Emulation board */ +#define MACH_MSP_OTHER 255 /* PMC-Sierra unknown board type */ + #define CL_SIZE COMMAND_LINE_SIZE const char *get_system_type(void); diff --git a/include/asm-mips/mipsregs.h b/include/asm-mips/mipsregs.h index 9985cb7..bd683b6 100644 --- a/include/asm-mips/mipsregs.h +++ b/include/asm-mips/mipsregs.h @@ -15,6 +15,7 @@ #define _ASM_MIPSREGS_H #include #include +#include /* * The following macros are especially useful for __asm__ @@ -1292,10 +1293,39 @@ static inline void tlb_probe(void) static inline void tlb_read(void) { +#if MIPS34K_MISSED_ITLB_WAR + int res = 0; + + __asm__ __volatile__( + " .set push \n" + " .set noreorder \n" + " .set noat \n" + " .set mips32r2 \n" + " .word 0x41610001 # dvpe $1 \n" + " move %0, $1 \n" + " ehb \n" + " .set pop \n" + : "=r" (res)); + + instruction_hazard(); +#endif + __asm__ __volatile__( ".set noreorder\n\t" "tlbr\n\t" ".set reorder"); + +#if MIPS34K_MISSED_ITLB_WAR + if ((res & _ULCAST_(1))) + __asm__ __volatile__( + " .set push \n" + " .set noreorder \n" + " .set noat \n" + " .set mips32r2 \n" + " .word 0x41600021 # evpe \n" + " ehb \n" + " .set pop \n"); +#endif } static inline void tlb_write_indexed(void) diff --git a/include/asm-mips/war.h b/include/asm-mips/war.h index 13a3502..74c08e6 100644 --- a/include/asm-mips/war.h +++ b/include/asm-mips/war.h @@ -196,6 +196,14 @@ #define R10000_LLSC_WAR 1 #endif /* + * 34K core erratum: "Problems Executing the TLBR Instruction" + */ +#if defined(CONFIG_PMC_MSP7120_EVAL) || defined(CONFIG_PMC_MSP7120_GW) || \ + defined(CONFIG_PMC_MSP7120_FPGA) +#define MIPS34K_MISSED_ITLB_WAR 1 +#endif + +/* * Workarounds default to off */ #ifndef ICACHE_REFILLS_WORKAROUND_WAR @@ -234,5 +242,8 @@ #endif #ifndef R10000_LLSC_WAR #define R10000_LLSC_WAR 0 #endif +#ifndef MIPS34K_MISSED_ITLB_WAR +#define MIPS34K_MISSED_ITLB_WAR 0 +#endif #endif /* _ASM_WAR_H */ From stjeanma@pmc-sierra.com Fri Feb 16 21:01:22 2007 Received: with ECARTIS (v1.0.0; list linux-mips); Fri, 16 Feb 2007 21:01:27 +0000 (GMT) Received: from father.pmc-sierra.com ([216.241.224.13]:17140 "HELO father.pmc-sierra.bc.ca") by ftp.linux-mips.org with SMTP id S28573790AbXBPVBW (ORCPT ); Fri, 16 Feb 2007 21:01:22 +0000 Received: (qmail 15992 invoked by uid 101); 16 Feb 2007 21:00:15 -0000 Received: from unknown (HELO pmxedge2.pmc-sierra.bc.ca) (216.241.226.184) by father.pmc-sierra.com with SMTP; 16 Feb 2007 21:00:15 -0000 Received: from pasqua.pmc-sierra.bc.ca (pasqua.pmc-sierra.bc.ca [134.87.183.161]) by pmxedge2.pmc-sierra.bc.ca (8.13.4/8.12.7) with ESMTP id l1GL0BxC019712 for ; Fri, 16 Feb 2007 13:00:12 -0800 From: Marc St-Jean Received: (from stjeanma@localhost) by pasqua.pmc-sierra.bc.ca (8.13.4/8.12.11) id l1GL0A8w003710 for linux-mips@linux-mips.org; Fri, 16 Feb 2007 15:00:10 -0600 Date: Fri, 16 Feb 2007 15:00:10 -0600 Message-Id: <200702162100.l1GL0A8w003710@pasqua.pmc-sierra.bc.ca> To: linux-mips@linux-mips.org Subject: [PATCH 2/2] PMC MSP71xx mips-common patch, kernel linux-mips.git master Return-Path: X-Envelope-To: <"|/home/ecartis/ecartis -s linux-mips"> (uid 0) X-Orcpt: rfc822;linux-mips@linux-mips.org Original-Recipient: rfc822;linux-mips@linux-mips.org X-archive-position: 14133 X-ecartis-version: Ecartis v1.0.0 Sender: linux-mips-bounce@linux-mips.org Errors-to: linux-mips-bounce@linux-mips.org X-original-sender: stjeanma@pmc-sierra.com Precedence: bulk X-list: linux-mips MIPS-common patch for the PMC-Sierra MSP71xx devices. This patch only contains the code living in arch/mips. Please provide any initial feedback. I will update and repost for consideration in the linux-mips.org repository. Thanks, Marc Signed-off-by: Marc St-Jean --- arch/mips/Kconfig | 81 + arch/mips/Makefile | 8 arch/mips/configs/msp71xx_defconfig | 1462 ++++++++++++++++++++++++++++++++++++ arch/mips/kernel/head.S | 8 arch/mips/kernel/traps.c | 19 include/asm-mips/bootinfo.h | 12 include/asm-mips/mipsregs.h | 30 include/asm-mips/war.h | 11 8 files changed, 1624 insertions(+), 7 deletions(-) diff --git a/arch/mips/Kconfig b/arch/mips/Kconfig index da26de5..c8a1eb9 100644 --- a/arch/mips/Kconfig +++ b/arch/mips/Kconfig @@ -491,6 +491,24 @@ config MACH_VR41XX select SYS_SUPPORTS_64BIT_KERNEL if EXPERIMENTAL select GENERIC_HARDIRQS_NO__DO_IRQ +config PMC_MSP + bool "PMC-Sierra MSP chipsets" + depends on EXPERIMENTAL + select DMA_NONCOHERENT + select SWAP_IO_SPACE + select SYS_HAS_CPU_MIPS32_R1 + select SYS_HAS_CPU_MIPS32_R2 + select SYS_SUPPORTS_32BIT_KERNEL + select SYS_SUPPORTS_BIG_ENDIAN + select IRQ_CPU + select SERIAL_8250 + select SERIAL_8250_CONSOLE + help + This adds support for the PMC-Sierra family of Multi-Service + Processor System-On-A-Chips. These parts include a number + of integrated peripherals, interfaces and DSPs in addition to + a variety of MIPS cores. + config PMC_YOSEMITE bool "PMC-Sierra Yosemite eval board" select DMA_COHERENT @@ -807,6 +825,59 @@ config KEXEC support. As of this writing the exact hardware interface is strongly in flux, so no good recommendation can be made. +choice + prompt "PMC-Sierra MSP SOC type" + depends on PMC_MSP + +config PMC_MSP4200_EVAL + bool "PMC-Sierra MSP4200 Eval Board" + select IRQ_MSP_SLP + select HW_HAS_PCI + +config PMC_MSP4200_GW + bool "PMC-Sierra MSP4200 VoIP Gateway" + select IRQ_MSP_SLP + select HW_HAS_PCI + +config PMC_MSP7120_EVAL + bool "PMC-Sierra MSP7120 Eval Board" + select SYS_SUPPORTS_MULTITHREADING + select IRQ_MSP_CIC + select HW_HAS_PCI + select MSP_USB + +config PMC_MSP7120_GW + bool "PMC-Sierra MSP7120 Residential Gateway" + select SYS_SUPPORTS_MULTITHREADING + select IRQ_MSP_CIC + select HW_HAS_PCI + select MSP_USB + +config PMC_MSP7120_FPGA + bool "PMC-Sierra MSP7120 FPGA" + select SYS_SUPPORTS_MULTITHREADING + select IRQ_MSP_CIC + select HW_HAS_PCI + select MSP_USB + +endchoice + +menu "Options for PMC-Sierra MSP chipsets" + depends on PMC_MSP + +config PMC_MSP_EMBEDDED_ROOTFS + bool "Root filesystem embedded in kernel image" + select MTD + select MTD_BLOCK + select MTD_PMC_MSP_RAMROOT + select MTD_RAM + +config PMC_MSP_UNCACHED + bool "Run uncached" + select MIPS_UNCACHED + +endmenu + source "arch/mips/ddb5xxx/Kconfig" source "arch/mips/gt64120/ev64120/Kconfig" source "arch/mips/jazz/Kconfig" @@ -963,6 +1034,15 @@ config IRQ_CPU_RM9K config IRQ_MV64340 bool +config IRQ_MSP_SLP + bool + +config IRQ_MSP_CIC + bool + +config MSP_USB + bool + config DDB5XXX_COMMON bool @@ -1074,6 +1154,7 @@ config MIPS_L1_CACHE_SHIFT int default "4" if MACH_DECSTATION default "7" if SGI_IP27 + default "4" if PMC_MSP4200_EVAL default "5" config HAVE_STD_PC_SERIAL_PORT diff --git a/arch/mips/Makefile b/arch/mips/Makefile index d1b026a..02bae07 100644 --- a/arch/mips/Makefile +++ b/arch/mips/Makefile @@ -365,6 +365,14 @@ cflags-$(CONFIG_PMC_YOSEMITE) += -Iinclu load-$(CONFIG_PMC_YOSEMITE) += 0xffffffff80100000 # +# PMC-Sierra MSP SOCs +# +core-$(CONFIG_PMC_MSP) += arch/mips/pmc-sierra/msp71xx/ +cflags-$(CONFIG_PMC_MSP) += -Iinclude/asm-mips/pmc-sierra/msp71xx \ + -mno-branch-likely +load-$(CONFIG_PMC_MSP) += 0xffffffff80100000 + +# # Qemu simulating MIPS32 4Kc # core-$(CONFIG_QEMU) += arch/mips/qemu/ diff --git a/arch/mips/configs/msp71xx_defconfig b/arch/mips/configs/msp71xx_defconfig new file mode 100644 index 0000000..d336490 --- /dev/null +++ b/arch/mips/configs/msp71xx_defconfig @@ -0,0 +1,1462 @@ +# +# Automatically generated make config: don't edit +# Linux kernel version: 2.6.20-rc5 +# Wed Feb 14 17:11:05 2007 +# +CONFIG_MIPS=y + +# +# Machine selection +# +# CONFIG_MIPS_MTX1 is not set +# CONFIG_MIPS_BOSPORUS is not set +# CONFIG_MIPS_PB1000 is not set +# CONFIG_MIPS_PB1100 is not set +# CONFIG_MIPS_PB1500 is not set +# CONFIG_MIPS_PB1550 is not set +# CONFIG_MIPS_PB1200 is not set +# CONFIG_MIPS_DB1000 is not set +# CONFIG_MIPS_DB1100 is not set +# CONFIG_MIPS_DB1500 is not set +# CONFIG_MIPS_DB1550 is not set +# CONFIG_MIPS_DB1200 is not set +# CONFIG_MIPS_MIRAGE is not set +# CONFIG_BASLER_EXCITE is not set +# CONFIG_MIPS_COBALT is not set +# CONFIG_MACH_DECSTATION is not set +# CONFIG_MIPS_EV64120 is not set +# CONFIG_MACH_JAZZ is not set +# CONFIG_LASAT is not set +# CONFIG_MIPS_ATLAS is not set +# CONFIG_MIPS_MALTA is not set +# CONFIG_MIPS_SEAD is not set +# CONFIG_WR_PPMC is not set +# CONFIG_MIPS_SIM is not set +# CONFIG_MOMENCO_JAGUAR_ATX is not set +# CONFIG_MOMENCO_OCELOT is not set +# CONFIG_MOMENCO_OCELOT_3 is not set +# CONFIG_MOMENCO_OCELOT_C is not set +# CONFIG_MOMENCO_OCELOT_G is not set +# CONFIG_MIPS_XXS1500 is not set +# CONFIG_PNX8550_V2PCI is not set +# CONFIG_PNX8550_JBS is not set +# CONFIG_PNX8550_STB810 is not set +# CONFIG_DDB5477 is not set +# CONFIG_MACH_VR41XX is not set +CONFIG_PMC_MSP=y +# CONFIG_PMC_YOSEMITE is not set +# CONFIG_QEMU is not set +# CONFIG_MARKEINS is not set +# CONFIG_SGI_IP22 is not set +# CONFIG_SGI_IP27 is not set +# CONFIG_SGI_IP32 is not set +# CONFIG_SIBYTE_BIGSUR is not set +# CONFIG_SIBYTE_SWARM is not set +# CONFIG_SIBYTE_SENTOSA is not set +# CONFIG_SIBYTE_RHONE is not set +# CONFIG_SIBYTE_CARMEL is not set +# CONFIG_SIBYTE_PTSWARM is not set +# CONFIG_SIBYTE_LITTLESUR is not set +# CONFIG_SIBYTE_CRHINE is not set +# CONFIG_SIBYTE_CRHONE is not set +# CONFIG_SNI_RM is not set +# CONFIG_TOSHIBA_JMR3927 is not set +# CONFIG_TOSHIBA_RBTX4927 is not set +# CONFIG_TOSHIBA_RBTX4938 is not set +# CONFIG_KEXEC is not set +# CONFIG_PMC_MSP4200_EVAL is not set +# CONFIG_PMC_MSP4200_GW is not set +# CONFIG_PMC_MSP7120_EVAL is not set +CONFIG_PMC_MSP7120_GW=y +# CONFIG_PMC_MSP7120_FPGA is not set + +# +# Options for PMC-Sierra MSP chipsets +# +CONFIG_PMC_MSP_EMBEDDED_ROOTFS=y +# CONFIG_PMC_MSP_UNCACHED is not set +CONFIG_RWSEM_GENERIC_SPINLOCK=y +# CONFIG_ARCH_HAS_ILOG2_U32 is not set +# CONFIG_ARCH_HAS_ILOG2_U64 is not set +CONFIG_GENERIC_FIND_NEXT_BIT=y +CONFIG_GENERIC_HWEIGHT=y +CONFIG_GENERIC_CALIBRATE_DELAY=y +CONFIG_GENERIC_TIME=y +CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y +# CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set +CONFIG_DMA_NONCOHERENT=y +CONFIG_DMA_NEED_PCI_MAP_STATE=y +CONFIG_CPU_BIG_ENDIAN=y +# CONFIG_CPU_LITTLE_ENDIAN is not set +CONFIG_SYS_SUPPORTS_BIG_ENDIAN=y +CONFIG_IRQ_CPU=y +CONFIG_IRQ_MSP_CIC=y +CONFIG_MSP_USB=y +CONFIG_SWAP_IO_SPACE=y +CONFIG_MIPS_L1_CACHE_SHIFT=5 + +# +# CPU selection +# +# CONFIG_CPU_MIPS32_R1 is not set +CONFIG_CPU_MIPS32_R2=y +# CONFIG_CPU_MIPS64_R1 is not set +# CONFIG_CPU_MIPS64_R2 is not set +# CONFIG_CPU_R3000 is not set +# CONFIG_CPU_TX39XX is not set +# CONFIG_CPU_VR41XX is not set +# CONFIG_CPU_R4300 is not set +# CONFIG_CPU_R4X00 is not set +# CONFIG_CPU_TX49XX is not set +# CONFIG_CPU_R5000 is not set +# CONFIG_CPU_R5432 is not set +# CONFIG_CPU_R6000 is not set +# CONFIG_CPU_NEVADA is not set +# CONFIG_CPU_R8000 is not set +# CONFIG_CPU_R10000 is not set +# CONFIG_CPU_RM7000 is not set +# CONFIG_CPU_RM9000 is not set +# CONFIG_CPU_SB1 is not set +CONFIG_SYS_HAS_CPU_MIPS32_R1=y +CONFIG_SYS_HAS_CPU_MIPS32_R2=y +CONFIG_CPU_MIPS32=y +CONFIG_CPU_MIPSR2=y +CONFIG_SYS_SUPPORTS_32BIT_KERNEL=y +CONFIG_CPU_SUPPORTS_32BIT_KERNEL=y + +# +# Kernel type +# +CONFIG_32BIT=y +# CONFIG_64BIT is not set +CONFIG_PAGE_SIZE_4KB=y +# CONFIG_PAGE_SIZE_8KB is not set +# CONFIG_PAGE_SIZE_16KB is not set +# CONFIG_PAGE_SIZE_64KB is not set +CONFIG_CPU_HAS_PREFETCH=y +CONFIG_MIPS_MT_DISABLED=y +# CONFIG_MIPS_MT_SMP is not set +# CONFIG_MIPS_MT_SMTC is not set +# CONFIG_MIPS_VPE_LOADER is not set +CONFIG_SYS_SUPPORTS_MULTITHREADING=y +# CONFIG_64BIT_PHYS_ADDR is not set +CONFIG_CPU_HAS_LLSC=y +CONFIG_CPU_HAS_SYNC=y +CONFIG_GENERIC_HARDIRQS=y +CONFIG_GENERIC_IRQ_PROBE=y +CONFIG_CPU_SUPPORTS_HIGHMEM=y +CONFIG_ARCH_FLATMEM_ENABLE=y +CONFIG_SELECT_MEMORY_MODEL=y +CONFIG_FLATMEM_MANUAL=y +# CONFIG_DISCONTIGMEM_MANUAL is not set +# CONFIG_SPARSEMEM_MANUAL is not set +CONFIG_FLATMEM=y +CONFIG_FLAT_NODE_MEM_MAP=y +# CONFIG_SPARSEMEM_STATIC is not set +CONFIG_SPLIT_PTLOCK_CPUS=4 +# CONFIG_RESOURCES_64BIT is not set +# CONFIG_HZ_48 is not set +# CONFIG_HZ_100 is not set +# CONFIG_HZ_128 is not set +CONFIG_HZ_250=y +# CONFIG_HZ_256 is not set +# CONFIG_HZ_1000 is not set +# CONFIG_HZ_1024 is not set +CONFIG_SYS_SUPPORTS_ARBIT_HZ=y +CONFIG_HZ=250 +# CONFIG_PREEMPT_NONE is not set +# CONFIG_PREEMPT_VOLUNTARY is not set +CONFIG_PREEMPT=y +# CONFIG_PREEMPT_BKL is not set +CONFIG_LOCKDEP_SUPPORT=y +CONFIG_STACKTRACE_SUPPORT=y +CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" + +# +# Code maturity level options +# +CONFIG_EXPERIMENTAL=y +CONFIG_BROKEN_ON_SMP=y +CONFIG_LOCK_KERNEL=y +CONFIG_INIT_ENV_ARG_LIMIT=32 + +# +# General setup +# +CONFIG_LOCALVERSION="-pmc" +CONFIG_LOCALVERSION_AUTO=y +# CONFIG_SWAP is not set +CONFIG_SYSVIPC=y +# CONFIG_IPC_NS is not set +# CONFIG_POSIX_MQUEUE is not set +# CONFIG_BSD_PROCESS_ACCT is not set +# CONFIG_TASKSTATS is not set +# CONFIG_UTS_NS is not set +# CONFIG_AUDIT is not set +# CONFIG_IKCONFIG is not set +CONFIG_SYSFS_DEPRECATED=y +# CONFIG_RELAY is not set +CONFIG_INITRAMFS_SOURCE="" +# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set +CONFIG_SYSCTL=y +CONFIG_EMBEDDED=y +CONFIG_SYSCTL_SYSCALL=y +CONFIG_KALLSYMS=y +# CONFIG_KALLSYMS_ALL is not set +# CONFIG_KALLSYMS_EXTRA_PASS is not set +CONFIG_HOTPLUG=y +CONFIG_PRINTK=y +CONFIG_BUG=y +CONFIG_ELF_CORE=y +CONFIG_BASE_FULL=y +CONFIG_FUTEX=y +CONFIG_EPOLL=y +# CONFIG_SHMEM is not set +CONFIG_SLAB=y +CONFIG_VM_EVENT_COUNTERS=y +CONFIG_RT_MUTEXES=y +CONFIG_TINY_SHMEM=y +CONFIG_BASE_SMALL=0 +# CONFIG_SLOB is not set + +# +# Loadable module support +# +CONFIG_MODULES=y +CONFIG_MODULE_UNLOAD=y +# CONFIG_MODULE_FORCE_UNLOAD is not set +CONFIG_MODVERSIONS=y +# CONFIG_MODULE_SRCVERSION_ALL is not set +CONFIG_KMOD=y + +# +# Block layer +# +CONFIG_BLOCK=y +# CONFIG_LBD is not set +# CONFIG_BLK_DEV_IO_TRACE is not set +# CONFIG_LSF is not set + +# +# IO Schedulers +# +CONFIG_IOSCHED_NOOP=y +CONFIG_IOSCHED_AS=y +# CONFIG_IOSCHED_DEADLINE is not set +# CONFIG_IOSCHED_CFQ is not set +CONFIG_DEFAULT_AS=y +# CONFIG_DEFAULT_DEADLINE is not set +# CONFIG_DEFAULT_CFQ is not set +# CONFIG_DEFAULT_NOOP is not set +CONFIG_DEFAULT_IOSCHED="anticipatory" + +# +# Bus options (PCI, PCMCIA, EISA, ISA, TC) +# +CONFIG_HW_HAS_PCI=y +CONFIG_PCI=y +# CONFIG_PCI_DEBUG is not set +CONFIG_MMU=y + +# +# PCCARD (PCMCIA/CardBus) support +# +# CONFIG_PCCARD is not set + +# +# PCI Hotplug Support +# +# CONFIG_HOTPLUG_PCI is not set + +# +# Executable file formats +# +CONFIG_BINFMT_ELF=y +# CONFIG_BINFMT_MISC is not set +CONFIG_TRAD_SIGNALS=y + +# +# Networking +# +CONFIG_NET=y + +# +# Networking options +# +# CONFIG_NETDEBUG is not set +# CONFIG_PACKET is not set +CONFIG_UNIX=y +CONFIG_XFRM=y +CONFIG_XFRM_USER=y +# CONFIG_XFRM_SUB_POLICY is not set +CONFIG_NET_KEY=y +CONFIG_INET=y +CONFIG_IP_MULTICAST=y +# CONFIG_IP_ADVANCED_ROUTER is not set +CONFIG_IP_FIB_HASH=y +CONFIG_IP_PNP=y +CONFIG_IP_PNP_DHCP=y +CONFIG_IP_PNP_BOOTP=y +# CONFIG_IP_PNP_RARP is not set +# CONFIG_NET_IPIP is not set +# CONFIG_NET_IPGRE is not set +# CONFIG_IP_MROUTE is not set +# CONFIG_ARPD is not set +# CONFIG_SYN_COOKIES is not set +CONFIG_INET_AH=y +CONFIG_INET_ESP=y +CONFIG_INET_IPCOMP=y +CONFIG_INET_XFRM_TUNNEL=y +CONFIG_INET_TUNNEL=y +CONFIG_INET_XFRM_MODE_TRANSPORT=y +CONFIG_INET_XFRM_MODE_TUNNEL=y +CONFIG_INET_XFRM_MODE_BEET=y +CONFIG_INET_DIAG=y +CONFIG_INET_TCP_DIAG=y +# CONFIG_TCP_CONG_ADVANCED is not set +CONFIG_TCP_CONG_CUBIC=y +CONFIG_DEFAULT_TCP_CONG="cubic" +# CONFIG_TCP_MD5SIG is not set + +# +# IP: Virtual Server Configuration +# +# CONFIG_IP_VS is not set +# CONFIG_IPV6 is not set +# CONFIG_INET6_XFRM_TUNNEL is not set +# CONFIG_INET6_TUNNEL is not set +# CONFIG_NETWORK_SECMARK is not set +CONFIG_NETFILTER=y +# CONFIG_NETFILTER_DEBUG is not set +CONFIG_BRIDGE_NETFILTER=y + +# +# Core Netfilter Configuration +# +# CONFIG_NETFILTER_NETLINK is not set +# CONFIG_NF_CONNTRACK_ENABLED is not set +CONFIG_NETFILTER_XTABLES=y +# CONFIG_NETFILTER_XT_TARGET_CLASSIFY is not set +# CONFIG_NETFILTER_XT_TARGET_MARK is not set +# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set +# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set +# CONFIG_NETFILTER_XT_MATCH_COMMENT is not set +# CONFIG_NETFILTER_XT_MATCH_DCCP is not set +# CONFIG_NETFILTER_XT_MATCH_DSCP is not set +# CONFIG_NETFILTER_XT_MATCH_ESP is not set +# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set +# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set +# CONFIG_NETFILTER_XT_MATCH_MAC is not set +# CONFIG_NETFILTER_XT_MATCH_MARK is not set +# CONFIG_NETFILTER_XT_MATCH_POLICY is not set +# CONFIG_NETFILTER_XT_MATCH_MULTIPORT is not set +# CONFIG_NETFILTER_XT_MATCH_PHYSDEV is not set +# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set +# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set +# CONFIG_NETFILTER_XT_MATCH_REALM is not set +# CONFIG_NETFILTER_XT_MATCH_SCTP is not set +# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set +# CONFIG_NETFILTER_XT_MATCH_STRING is not set +# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set +# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set + +# +# IP: Netfilter Configuration +# +# CONFIG_IP_NF_QUEUE is not set +CONFIG_IP_NF_IPTABLES=y +# CONFIG_IP_NF_MATCH_IPRANGE is not set +# CONFIG_IP_NF_MATCH_TOS is not set +# CONFIG_IP_NF_MATCH_RECENT is not set +# CONFIG_IP_NF_MATCH_ECN is not set +# CONFIG_IP_NF_MATCH_AH is not set +# CONFIG_IP_NF_MATCH_TTL is not set +# CONFIG_IP_NF_MATCH_OWNER is not set +# CONFIG_IP_NF_MATCH_ADDRTYPE is not set +CONFIG_IP_NF_FILTER=y +CONFIG_IP_NF_TARGET_REJECT=y +# CONFIG_IP_NF_TARGET_LOG is not set +# CONFIG_IP_NF_TARGET_ULOG is not set +# CONFIG_IP_NF_TARGET_TCPMSS is not set +# CONFIG_IP_NF_MANGLE is not set +# CONFIG_IP_NF_RAW is not set +# CONFIG_IP_NF_ARPTABLES is not set + +# +# Bridge: Netfilter Configuration +# +# CONFIG_BRIDGE_NF_EBTABLES is not set + +# +# DCCP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_DCCP is not set + +# +# SCTP Configuration (EXPERIMENTAL) +# +# CONFIG_IP_SCTP is not set + +# +# TIPC Configuration (EXPERIMENTAL) +# +# CONFIG_TIPC is not set +# CONFIG_ATM is not set +CONFIG_BRIDGE=y +# CONFIG_VLAN_8021Q is not set +# CONFIG_DECNET is not set +CONFIG_LLC=y +# CONFIG_LLC2 is not set +# CONFIG_IPX is not set +# CONFIG_ATALK is not set +# CONFIG_X25 is not set +# CONFIG_LAPB is not set +# CONFIG_ECONET is not set +# CONFIG_WAN_ROUTER is not set + +# +# QoS and/or fair queueing +# +# CONFIG_NET_SCHED is not set + +# +# Network testing +# +# CONFIG_NET_PKTGEN is not set +# CONFIG_HAMRADIO is not set +# CONFIG_IRDA is not set +# CONFIG_BT is not set +# CONFIG_IEEE80211 is not set +CONFIG_WIRELESS_EXT=y + +# +# Device Drivers +# + +# +# Generic Driver Options +# +CONFIG_STANDALONE=y +# CONFIG_PREVENT_FIRMWARE_BUILD is not set +# CONFIG_FW_LOADER is not set +# CONFIG_DEBUG_DRIVER is not set +# CONFIG_SYS_HYPERVISOR is not set + +# +# Connector - unified userspace <-> kernelspace linker +# +# CONFIG_CONNECTOR is not set + +# +# Memory Technology Devices (MTD) +# +CONFIG_MTD=y +# CONFIG_MTD_DEBUG is not set +# CONFIG_MTD_CONCAT is not set +CONFIG_MTD_PARTITIONS=y +# CONFIG_MTD_REDBOOT_PARTS is not set +# CONFIG_MTD_CMDLINE_PARTS is not set + +# +# User Modules And Translation Layers +# +CONFIG_MTD_CHAR=y +CONFIG_MTD_BLOCK=y +# CONFIG_FTL is not set +# CONFIG_NFTL is not set +# CONFIG_INFTL is not set +# CONFIG_RFD_FTL is not set +# CONFIG_SSFDC is not set + +# +# RAM/ROM/Flash chip drivers +# +CONFIG_MTD_CFI=y +# CONFIG_MTD_JEDECPROBE is not set +CONFIG_MTD_GEN_PROBE=y +# CONFIG_MTD_CFI_ADV_OPTIONS is not set +CONFIG_MTD_MAP_BANK_WIDTH_1=y +CONFIG_MTD_MAP_BANK_WIDTH_2=y +CONFIG_MTD_MAP_BANK_WIDTH_4=y +# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set +# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set +CONFIG_MTD_CFI_I1=y +CONFIG_MTD_CFI_I2=y +# CONFIG_MTD_CFI_I4 is not set +# CONFIG_MTD_CFI_I8 is not set +# CONFIG_MTD_CFI_INTELEXT is not set +CONFIG_MTD_CFI_AMDSTD=y +# CONFIG_MTD_CFI_STAA is not set +CONFIG_MTD_CFI_UTIL=y +CONFIG_MTD_RAM=y +# CONFIG_MTD_ROM is not set +# CONFIG_MTD_ABSENT is not set +# CONFIG_MTD_OBSOLETE_CHIPS is not set + +# +# Mapping drivers for chip access +# +# CONFIG_MTD_COMPLEX_MAPPINGS is not set +# CONFIG_MTD_PHYSMAP is not set +CONFIG_MTD_PMC_MSP_EVM=y +CONFIG_MSP_FLASH_MAP_LIMIT_32M=y +CONFIG_MSP_FLASH_MAP_LIMIT=0x02000000 +CONFIG_MTD_PMC_MSP_RAMROOT=y +# CONFIG_MTD_PLATRAM is not set + +# +# Self-contained MTD device drivers +# +# CONFIG_MTD_PMC551 is not set +# CONFIG_MTD_SLRAM is not set +# CONFIG_MTD_PHRAM is not set +CONFIG_MTD_MTDRAM=y +CONFIG_MTDRAM_TOTAL_SIZE=0 +CONFIG_MTDRAM_ERASE_SIZE=0 +CONFIG_MTDRAM_ABS_POS=0 +# CONFIG_MTD_BLOCK2MTD is not set + +# +# Disk-On-Chip Device Drivers +# +# CONFIG_MTD_DOC2000 is not set +# CONFIG_MTD_DOC2001 is not set +# CONFIG_MTD_DOC2001PLUS is not set + +# +# NAND Flash Device Drivers +# +# CONFIG_MTD_NAND is not set + +# +# OneNAND Flash Device Drivers +# +# CONFIG_MTD_ONENAND is not set + +# +# Parallel port support +# +# CONFIG_PARPORT is not set + +# +# Plug and Play support +# + +# +# Block devices +# +# CONFIG_BLK_CPQ_DA is not set +# CONFIG_BLK_CPQ_CISS_DA is not set +# CONFIG_BLK_DEV_DAC960 is not set +# CONFIG_BLK_DEV_UMEM is not set +# CONFIG_BLK_DEV_COW_COMMON is not set +# CONFIG_BLK_DEV_LOOP is not set +# CONFIG_BLK_DEV_NBD is not set +# CONFIG_BLK_DEV_SX8 is not set +# CONFIG_BLK_DEV_UB is not set +CONFIG_BLK_DEV_RAM=y +CONFIG_BLK_DEV_RAM_COUNT=16 +CONFIG_BLK_DEV_RAM_SIZE=4096 +CONFIG_BLK_DEV_RAM_BLOCKSIZE=1024 +# CONFIG_BLK_DEV_INITRD is not set +# CONFIG_CDROM_PKTCDVD is not set +# CONFIG_ATA_OVER_ETH is not set + +# +# Misc devices +# +# CONFIG_SGI_IOC4 is not set +# CONFIG_TIFM_CORE is not set + +# +# ATA/ATAPI/MFM/RLL support +# +# CONFIG_IDE is not set + +# +# SCSI device support +# +# CONFIG_RAID_ATTRS is not set +CONFIG_SCSI=y +# CONFIG_SCSI_TGT is not set +# CONFIG_SCSI_NETLINK is not set +CONFIG_SCSI_PROC_FS=y + +# +# SCSI support type (disk, tape, CD-ROM) +# +CONFIG_BLK_DEV_SD=y +# CONFIG_CHR_DEV_ST is not set +# CONFIG_CHR_DEV_OSST is not set +# CONFIG_BLK_DEV_SR is not set +# CONFIG_CHR_DEV_SG is not set +# CONFIG_CHR_DEV_SCH is not set + +# +# Some SCSI devices (e.g. CD jukebox) support multiple LUNs +# +# CONFIG_SCSI_MULTI_LUN is not set +# CONFIG_SCSI_CONSTANTS is not set +# CONFIG_SCSI_LOGGING is not set +# CONFIG_SCSI_SCAN_ASYNC is not set + +# +# SCSI Transports +# +# CONFIG_SCSI_SPI_ATTRS is not set +# CONFIG_SCSI_FC_ATTRS is not set +# CONFIG_SCSI_ISCSI_ATTRS is not set +# CONFIG_SCSI_SAS_ATTRS is not set +# CONFIG_SCSI_SAS_LIBSAS is not set + +# +# SCSI low-level drivers +# +# CONFIG_ISCSI_TCP is not set +# CONFIG_BLK_DEV_3W_XXXX_RAID is not set +# CONFIG_SCSI_3W_9XXX is not set +# CONFIG_SCSI_ACARD is not set +# CONFIG_SCSI_AACRAID is not set +# CONFIG_SCSI_AIC7XXX is not set +# CONFIG_SCSI_AIC7XXX_OLD is not set +# CONFIG_SCSI_AIC79XX is not set +# CONFIG_SCSI_AIC94XX is not set +# CONFIG_SCSI_DPT_I2O is not set +# CONFIG_SCSI_ARCMSR is not set +# CONFIG_MEGARAID_NEWGEN is not set +# CONFIG_MEGARAID_LEGACY is not set +# CONFIG_MEGARAID_SAS is not set +# CONFIG_SCSI_HPTIOP is not set +# CONFIG_SCSI_DMX3191D is not set +# CONFIG_SCSI_FUTURE_DOMAIN is not set +# CONFIG_SCSI_IPS is not set +# CONFIG_SCSI_INITIO is not set +# CONFIG_SCSI_INIA100 is not set +# CONFIG_SCSI_STEX is not set +# CONFIG_SCSI_SYM53C8XX_2 is not set +# CONFIG_SCSI_QLOGIC_1280 is not set +# CONFIG_SCSI_QLA_FC is not set +# CONFIG_SCSI_QLA_ISCSI is not set +# CONFIG_SCSI_LPFC is not set +# CONFIG_SCSI_DC395x is not set +# CONFIG_SCSI_DC390T is not set +# CONFIG_SCSI_NSP32 is not set +# CONFIG_SCSI_DEBUG is not set +# CONFIG_SCSI_SRP is not set + +# +# Serial ATA (prod) and Parallel ATA (experimental) drivers +# +# CONFIG_ATA is not set + +# +# Multi-device support (RAID and LVM) +# +# CONFIG_MD is not set + +# +# Fusion MPT device support +# +# CONFIG_FUSION is not set +# CONFIG_FUSION_SPI is not set +# CONFIG_FUSION_FC is not set +# CONFIG_FUSION_SAS is not set + +# +# IEEE 1394 (FireWire) support +# +# CONFIG_IEEE1394 is not set + +# +# I2O device support +# +# CONFIG_I2O is not set + +# +# Network device support +# +CONFIG_NETDEVICES=y +CONFIG_DUMMY=y +# CONFIG_BONDING is not set +# CONFIG_EQUALIZER is not set +# CONFIG_TUN is not set + +# +# ARCnet devices +# +# CONFIG_ARCNET is not set + +# +# PHY device support +# +# CONFIG_PHYLIB is not set + +# +# Ethernet (10 or 100Mbit) +# +CONFIG_NET_ETHERNET=y +CONFIG_MII=y +# CONFIG_PMC_MSP_ETH is not set +# CONFIG_HAPPYMEAL is not set +# CONFIG_SUNGEM is not set +# CONFIG_CASSINI is not set +# CONFIG_NET_VENDOR_3COM is not set +# CONFIG_DM9000 is not set + +# +# Tulip family network device support +# +# CONFIG_NET_TULIP is not set +# CONFIG_HP100 is not set +# CONFIG_NET_PCI is not set + +# +# Ethernet (1000 Mbit) +# +# CONFIG_ACENIC is not set +# CONFIG_DL2K is not set +# CONFIG_E1000 is not set +# CONFIG_NS83820 is not set +# CONFIG_HAMACHI is not set +# CONFIG_YELLOWFIN is not set +# CONFIG_R8169 is not set +# CONFIG_SIS190 is not set +# CONFIG_SKGE is not set +# CONFIG_SKY2 is not set +# CONFIG_SK98LIN is not set +# CONFIG_TIGON3 is not set +# CONFIG_BNX2 is not set +# CONFIG_QLA3XXX is not set + +# +# Ethernet (10000 Mbit) +# +# CONFIG_CHELSIO_T1 is not set +# CONFIG_IXGB is not set +# CONFIG_S2IO is not set +# CONFIG_MYRI10GE is not set +# CONFIG_NETXEN_NIC is not set + +# +# Token Ring devices +# +# CONFIG_TR is not set + +# +# Wireless LAN (non-hamradio) +# +CONFIG_NET_RADIO=y +# CONFIG_NET_WIRELESS_RTNETLINK is not set + +# +# Obsolete Wireless cards support (pre-802.11) +# +# CONFIG_STRIP is not set + +# +# Wireless 802.11b ISA/PCI cards support +# +# CONFIG_IPW2100 is not set +# CONFIG_IPW2200 is not set +# CONFIG_HERMES is not set +# CONFIG_ATMEL is not set + +# +# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support +# +# CONFIG_PRISM54 is not set +# CONFIG_USB_ZD1201 is not set +# CONFIG_HOSTAP is not set +CONFIG_NET_WIRELESS=y + +# +# Wan interfaces +# +# CONFIG_WAN is not set +# CONFIG_FDDI is not set +# CONFIG_HIPPI is not set +CONFIG_PPP=y +# CONFIG_PPP_MULTILINK is not set +# CONFIG_PPP_FILTER is not set +# CONFIG_PPP_ASYNC is not set +# CONFIG_PPP_SYNC_TTY is not set +# CONFIG_PPP_DEFLATE is not set +# CONFIG_PPP_BSDCOMP is not set +# CONFIG_PPP_MPPE is not set +# CONFIG_PPPOE is not set +# CONFIG_SLIP is not set +CONFIG_SLHC=y +# CONFIG_NET_FC is not set +# CONFIG_SHAPER is not set +# CONFIG_NETCONSOLE is not set +# CONFIG_NETPOLL is not set +# CONFIG_NET_POLL_CONTROLLER is not set + +# +# ISDN subsystem +# +# CONFIG_ISDN is not set + +# +# Telephony Support +# +# CONFIG_PHONE is not set + +# +# Input device support +# +CONFIG_INPUT=y +# CONFIG_INPUT_FF_MEMLESS is not set + +# +# Userland interfaces +# +# CONFIG_INPUT_MOUSEDEV is not set +# CONFIG_INPUT_JOYDEV is not set +# CONFIG_INPUT_TSDEV is not set +# CONFIG_INPUT_EVDEV is not set +# CONFIG_INPUT_EVBUG is not set + +# +# Input Device Drivers +# +# CONFIG_INPUT_KEYBOARD is not set +# CONFIG_INPUT_MOUSE is not set +# CONFIG_INPUT_JOYSTICK is not set +# CONFIG_INPUT_TOUCHSCREEN is not set +# CONFIG_INPUT_MISC is not set + +# +# Hardware I/O ports +# +# CONFIG_SERIO is not set +# CONFIG_GAMEPORT is not set + +# +# Character devices +# +# CONFIG_VT is not set +# CONFIG_SERIAL_NONSTANDARD is not set +CONFIG_PMCMSP_GPIO=y + +# +# Serial drivers +# +CONFIG_SERIAL_8250=y +CONFIG_SERIAL_8250_CONSOLE=y +# CONFIG_SERIAL_8250_PCI is not set +CONFIG_SERIAL_8250_NR_UARTS=2 +CONFIG_SERIAL_8250_RUNTIME_UARTS=2 +# CONFIG_SERIAL_8250_EXTENDED is not set + +# +# Non-8250 serial port support +# +CONFIG_SERIAL_CORE=y +CONFIG_SERIAL_CORE_CONSOLE=y +# CONFIG_SERIAL_JSM is not set +CONFIG_UNIX98_PTYS=y +# CONFIG_LEGACY_PTYS is not set + +# +# IPMI +# +# CONFIG_IPMI_HANDLER is not set + +# +# Watchdog Cards +# +# CONFIG_WATCHDOG is not set +# CONFIG_HW_RANDOM is not set +# CONFIG_RTC is not set +# CONFIG_GEN_RTC is not set +# CONFIG_DTLK is not set +# CONFIG_R3964 is not set +# CONFIG_APPLICOM is not set +# CONFIG_DRM is not set +# CONFIG_RAW_DRIVER is not set + +# +# TPM devices +# +# CONFIG_TCG_TPM is not set + +# +# I2C support +# +CONFIG_I2C=y +CONFIG_I2C_CHARDEV=y + +# +# I2C Algorithms +# +# CONFIG_I2C_ALGOBIT is not set +# CONFIG_I2C_ALGOPCF is not set +# CONFIG_I2C_ALGOPCA is not set + +# +# I2C Hardware Bus support +# +# CONFIG_I2C_ALI1535 is not set +# CONFIG_I2C_ALI1563 is not set +# CONFIG_I2C_ALI15X3 is not set +# CONFIG_I2C_AMD756 is not set +# CONFIG_I2C_AMD8111 is not set +# CONFIG_I2C_I801 is not set +# CONFIG_I2C_I810 is not set +# CONFIG_I2C_PIIX4 is not set +# CONFIG_I2C_NFORCE2 is not set +# CONFIG_I2C_OCORES is not set +# CONFIG_I2C_PARPORT_LIGHT is not set +# CONFIG_I2C_PROSAVAGE is not set +# CONFIG_I2C_SAVAGE4 is not set +# CONFIG_I2C_SIS5595 is not set +# CONFIG_I2C_SIS630 is not set +# CONFIG_I2C_SIS96X is not set +# CONFIG_I2C_STUB is not set +# CONFIG_I2C_VIA is not set +# CONFIG_I2C_VIAPRO is not set +# CONFIG_I2C_VOODOO3 is not set +# CONFIG_I2C_PCA_ISA is not set + +# +# Miscellaneous I2C Chip support +# +# CONFIG_SENSORS_DS1337 is not set +# CONFIG_SENSORS_DS1374 is not set +# CONFIG_SENSORS_EEPROM is not set +# CONFIG_SENSORS_PCF8574 is not set +# CONFIG_SENSORS_PCA9539 is not set +# CONFIG_SENSORS_PCF8591 is not set +# CONFIG_SENSORS_MAX6875 is not set +# CONFIG_I2C_DEBUG_CORE is not set +# CONFIG_I2C_DEBUG_ALGO is not set +# CONFIG_I2C_DEBUG_BUS is not set +# CONFIG_I2C_DEBUG_CHIP is not set + +# +# SPI support +# +# CONFIG_SPI is not set +# CONFIG_SPI_MASTER is not set + +# +# Dallas's 1-wire bus +# +# CONFIG_W1 is not set + +# +# Hardware Monitoring support +# +CONFIG_HWMON=y +# CONFIG_HWMON_VID is not set +# CONFIG_SENSORS_ABITUGURU is not set +# CONFIG_SENSORS_ADM1021 is not set +# CONFIG_SENSORS_ADM1025 is not set +# CONFIG_SENSORS_ADM1026 is not set +# CONFIG_SENSORS_ADM1031 is not set +# CONFIG_SENSORS_ADM9240 is not set +# CONFIG_SENSORS_ASB100 is not set +# CONFIG_SENSORS_ATXP1 is not set +# CONFIG_SENSORS_DS1621 is not set +# CONFIG_SENSORS_F71805F is not set +# CONFIG_SENSORS_FSCHER is not set +# CONFIG_SENSORS_FSCPOS is not set +# CONFIG_SENSORS_GL518SM is not set +# CONFIG_SENSORS_GL520SM is not set +# CONFIG_SENSORS_IT87 is not set +# CONFIG_SENSORS_LM63 is not set +# CONFIG_SENSORS_LM75 is not set +# CONFIG_SENSORS_LM77 is not set +# CONFIG_SENSORS_LM78 is not set +# CONFIG_SENSORS_LM80 is not set +# CONFIG_SENSORS_LM83 is not set +# CONFIG_SENSORS_LM85 is not set +# CONFIG_SENSORS_LM87 is not set +# CONFIG_SENSORS_LM90 is not set +# CONFIG_SENSORS_LM92 is not set +# CONFIG_SENSORS_MAX1619 is not set +# CONFIG_SENSORS_PC87360 is not set +# CONFIG_SENSORS_PC87427 is not set +# CONFIG_SENSORS_SIS5595 is not set +# CONFIG_SENSORS_SMSC47M1 is not set +# CONFIG_SENSORS_SMSC47M192 is not set +# CONFIG_SENSORS_SMSC47B397 is not set +# CONFIG_SENSORS_VIA686A is not set +# CONFIG_SENSORS_VT1211 is not set +# CONFIG_SENSORS_VT8231 is not set +# CONFIG_SENSORS_W83781D is not set +# CONFIG_SENSORS_W83791D is not set +# CONFIG_SENSORS_W83792D is not set +# CONFIG_SENSORS_W83793 is not set +# CONFIG_SENSORS_W83L785TS is not set +# CONFIG_SENSORS_W83627HF is not set +# CONFIG_SENSORS_W83627EHF is not set +# CONFIG_HWMON_DEBUG_CHIP is not set + +# +# Multimedia devices +# +# CONFIG_VIDEO_DEV is not set + +# +# Digital Video Broadcasting Devices +# +# CONFIG_DVB is not set +# CONFIG_USB_DABUSB is not set + +# +# Graphics support +# +# CONFIG_FIRMWARE_EDID is not set +# CONFIG_FB is not set +# CONFIG_BACKLIGHT_LCD_SUPPORT is not set + +# +# Sound +# +# CONFIG_SOUND is not set + +# +# HID Devices +# +CONFIG_HID=y + +# +# USB support +# +CONFIG_USB_ARCH_HAS_HCD=y +CONFIG_USB_ARCH_HAS_OHCI=y +CONFIG_USB_ARCH_HAS_EHCI=y +CONFIG_USB=y +# CONFIG_USB_DEBUG is not set + +# +# Miscellaneous USB options +# +CONFIG_USB_DEVICEFS=y +# CONFIG_USB_BANDWIDTH is not set +# CONFIG_USB_DYNAMIC_MINORS is not set +# CONFIG_USB_MULTITHREAD_PROBE is not set +# CONFIG_USB_OTG is not set + +# +# USB Host Controller Drivers +# +CONFIG_USB_EHCI_HCD=y +# CONFIG_USB_EHCI_SPLIT_ISO is not set +CONFIG_USB_EHCI_ROOT_HUB_TT=y +# CONFIG_USB_EHCI_TT_NEWSCHED is not set +# CONFIG_USB_ISP116X_HCD is not set +# CONFIG_USB_OHCI_HCD is not set +# CONFIG_USB_UHCI_HCD is not set +# CONFIG_USB_SL811_HCD is not set + +# +# USB Device Class drivers +# +# CONFIG_USB_ACM is not set +# CONFIG_USB_PRINTER is not set + +# +# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' +# + +# +# may also be needed; see USB_STORAGE Help for more information +# +CONFIG_USB_STORAGE=y +# CONFIG_USB_STORAGE_DEBUG is not set +# CONFIG_USB_STORAGE_DATAFAB is not set +# CONFIG_USB_STORAGE_FREECOM is not set +# CONFIG_USB_STORAGE_DPCM is not set +# CONFIG_USB_STORAGE_USBAT is not set +# CONFIG_USB_STORAGE_SDDR09 is not set +# CONFIG_USB_STORAGE_SDDR55 is not set +# CONFIG_USB_STORAGE_JUMPSHOT is not set +# CONFIG_USB_STORAGE_ALAUDA is not set +# CONFIG_USB_STORAGE_KARMA is not set +# CONFIG_USB_LIBUSUAL is not set + +# +# USB Input Devices +# +# CONFIG_USB_HID is not set + +# +# USB HID Boot Protocol drivers +# +# CONFIG_USB_KBD is not set +# CONFIG_USB_MOUSE is not set +# CONFIG_USB_AIPTEK is not set +# CONFIG_USB_WACOM is not set +# CONFIG_USB_ACECAD is not set +# CONFIG_USB_KBTAB is not set +# CONFIG_USB_POWERMATE is not set +# CONFIG_USB_TOUCHSCREEN is not set +# CONFIG_USB_YEALINK is not set +# CONFIG_USB_XPAD is not set +# CONFIG_USB_ATI_REMOTE is not set +# CONFIG_USB_ATI_REMOTE2 is not set +# CONFIG_USB_KEYSPAN_REMOTE is not set +# CONFIG_USB_APPLETOUCH is not set + +# +# USB Imaging devices +# +# CONFIG_USB_MDC800 is not set +# CONFIG_USB_MICROTEK is not set + +# +# USB Network Adapters +# +# CONFIG_USB_CATC is not set +# CONFIG_USB_KAWETH is not set +# CONFIG_USB_PEGASUS is not set +# CONFIG_USB_RTL8150 is not set +# CONFIG_USB_USBNET_MII is not set +# CONFIG_USB_USBNET is not set +CONFIG_USB_MON=y + +# +# USB port drivers +# + +# +# USB Serial Converter support +# +# CONFIG_USB_SERIAL is not set + +# +# USB Miscellaneous drivers +# +# CONFIG_USB_EMI62 is not set +# CONFIG_USB_EMI26 is not set +# CONFIG_USB_ADUTUX is not set +# CONFIG_USB_AUERSWALD is not set +# CONFIG_USB_RIO500 is not set +# CONFIG_USB_LEGOTOWER is not set +# CONFIG_USB_LCD is not set +# CONFIG_USB_LED is not set +# CONFIG_USB_CYPRESS_CY7C63 is not set +# CONFIG_USB_CYTHERM is not set +# CONFIG_USB_PHIDGET is not set +# CONFIG_USB_IDMOUSE is not set +# CONFIG_USB_FTDI_ELAN is not set +# CONFIG_USB_APPLEDISPLAY is not set +# CONFIG_USB_SISUSBVGA is not set +# CONFIG_USB_LD is not set +# CONFIG_USB_TRANCEVIBRATOR is not set +# CONFIG_USB_TEST is not set + +# +# USB DSL modem support +# + +# +# USB Gadget Support +# +# CONFIG_USB_GADGET is not set + +# +# MMC/SD Card support +# +# CONFIG_MMC is not set + +# +# LED devices +# +# CONFIG_NEW_LEDS is not set + +# +# LED drivers +# + +# +# LED Triggers +# + +# +# InfiniBand support +# +# CONFIG_INFINIBAND is not set + +# +# EDAC - error detection and reporting (RAS) (EXPERIMENTAL) +# + +# +# Real Time Clock +# +# CONFIG_RTC_CLASS is not set + +# +# DMA Engine support +# +# CONFIG_DMA_ENGINE is not set + +# +# DMA Clients +# + +# +# DMA Devices +# + +# +# Virtualization +# + +# +# File systems +# +CONFIG_EXT2_FS=y +# CONFIG_EXT2_FS_XATTR is not set +# CONFIG_EXT2_FS_XIP is not set +# CONFIG_EXT3_FS is not set +# CONFIG_EXT4DEV_FS is not set +# CONFIG_REISERFS_FS is not set +# CONFIG_JFS_FS is not set +# CONFIG_FS_POSIX_ACL is not set +# CONFIG_XFS_FS is not set +# CONFIG_GFS2_FS is not set +# CONFIG_OCFS2_FS is not set +# CONFIG_MINIX_FS is not set +# CONFIG_ROMFS_FS is not set +# CONFIG_INOTIFY is not set +# CONFIG_QUOTA is not set +# CONFIG_DNOTIFY is not set +# CONFIG_AUTOFS_FS is not set +# CONFIG_AUTOFS4_FS is not set +# CONFIG_FUSE_FS is not set + +# +# CD-ROM/DVD Filesystems +# +# CONFIG_ISO9660_FS is not set +# CONFIG_UDF_FS is not set + +# +# DOS/FAT/NT Filesystems +# +CONFIG_FAT_FS=y +CONFIG_MSDOS_FS=y +CONFIG_VFAT_FS=y +CONFIG_FAT_DEFAULT_CODEPAGE=437 +CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" +# CONFIG_NTFS_FS is not set + +# +# Pseudo filesystems +# +CONFIG_PROC_FS=y +# CONFIG_PROC_KCORE is not set +CONFIG_PROC_SYSCTL=y +CONFIG_SYSFS=y +CONFIG_TMPFS=y +# CONFIG_TMPFS_POSIX_ACL is not set +# CONFIG_HUGETLB_PAGE is not set +CONFIG_RAMFS=y +# CONFIG_CONFIGFS_FS is not set + +# +# Miscellaneous filesystems +# +# CONFIG_ADFS_FS is not set +# CONFIG_AFFS_FS is not set +# CONFIG_HFS_FS is not set +# CONFIG_HFSPLUS_FS is not set +# CONFIG_BEFS_FS is not set +# CONFIG_BFS_FS is not set +# CONFIG_EFS_FS is not set +CONFIG_JFFS2_FS=y +CONFIG_JFFS2_FS_DEBUG=0 +CONFIG_JFFS2_FS_WRITEBUFFER=y +# CONFIG_JFFS2_SUMMARY is not set +# CONFIG_JFFS2_FS_XATTR is not set +# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set +CONFIG_JFFS2_ZLIB=y +CONFIG_JFFS2_RTIME=y +# CONFIG_JFFS2_RUBIN is not set +# CONFIG_CRAMFS is not set +CONFIG_SQUASHFS=y +CONFIG_SQUASHFS_EMBEDDED=y +CONFIG_SQUASHFS_FRAGMENT_CACHE_SIZE=3 +CONFIG_SQUASHFS_VMALLOC=y +# CONFIG_VXFS_FS is not set +# CONFIG_HPFS_FS is not set +# CONFIG_QNX4FS_FS is not set +# CONFIG_SYSV_FS is not set +# CONFIG_UFS_FS is not set + +# +# Network File Systems +# +# CONFIG_NFS_FS is not set +# CONFIG_NFSD is not set +# CONFIG_SMB_FS is not set +# CONFIG_CIFS is not set +# CONFIG_NCP_FS is not set +# CONFIG_CODA_FS is not set +# CONFIG_AFS_FS is not set +# CONFIG_9P_FS is not set + +# +# Partition Types +# +# CONFIG_PARTITION_ADVANCED is not set +CONFIG_MSDOS_PARTITION=y + +# +# Native Language Support +# +CONFIG_NLS=y +CONFIG_NLS_DEFAULT="iso8859-1" +CONFIG_NLS_CODEPAGE_437=y +# CONFIG_NLS_CODEPAGE_737 is not set +# CONFIG_NLS_CODEPAGE_775 is not set +# CONFIG_NLS_CODEPAGE_850 is not set +# CONFIG_NLS_CODEPAGE_852 is not set +# CONFIG_NLS_CODEPAGE_855 is not set +# CONFIG_NLS_CODEPAGE_857 is not set +# CONFIG_NLS_CODEPAGE_860 is not set +# CONFIG_NLS_CODEPAGE_861 is not set +# CONFIG_NLS_CODEPAGE_862 is not set +# CONFIG_NLS_CODEPAGE_863 is not set +# CONFIG_NLS_CODEPAGE_864 is not set +# CONFIG_NLS_CODEPAGE_865 is not set +# CONFIG_NLS_CODEPAGE_866 is not set +# CONFIG_NLS_CODEPAGE_869 is not set +# CONFIG_NLS_CODEPAGE_936 is not set +# CONFIG_NLS_CODEPAGE_950 is not set +# CONFIG_NLS_CODEPAGE_932 is not set +# CONFIG_NLS_CODEPAGE_949 is not set +# CONFIG_NLS_CODEPAGE_874 is not set +# CONFIG_NLS_ISO8859_8 is not set +# CONFIG_NLS_CODEPAGE_1250 is not set +# CONFIG_NLS_CODEPAGE_1251 is not set +# CONFIG_NLS_ASCII is not set +CONFIG_NLS_ISO8859_1=y +# CONFIG_NLS_ISO8859_2 is not set +# CONFIG_NLS_ISO8859_3 is not set +# CONFIG_NLS_ISO8859_4 is not set +# CONFIG_NLS_ISO8859_5 is not set +# CONFIG_NLS_ISO8859_6 is not set +# CONFIG_NLS_ISO8859_7 is not set +# CONFIG_NLS_ISO8859_9 is not set +# CONFIG_NLS_ISO8859_13 is not set +# CONFIG_NLS_ISO8859_14 is not set +# CONFIG_NLS_ISO8859_15 is not set +# CONFIG_NLS_KOI8_R is not set +# CONFIG_NLS_KOI8_U is not set +# CONFIG_NLS_UTF8 is not set + +# +# Distributed Lock Manager +# +# CONFIG_DLM is not set + +# +# Profiling support +# +# CONFIG_PROFILING is not set + +# +# Kernel hacking +# +CONFIG_TRACE_IRQFLAGS_SUPPORT=y +# CONFIG_PRINTK_TIME is not set +CONFIG_ENABLE_MUST_CHECK=y +CONFIG_MAGIC_SYSRQ=y +# CONFIG_UNUSED_SYMBOLS is not set +# CONFIG_DEBUG_FS is not set +# CONFIG_HEADERS_CHECK is not set +CONFIG_DEBUG_KERNEL=y +CONFIG_LOG_BUF_SHIFT=14 +CONFIG_DETECT_SOFTLOCKUP=y +# CONFIG_SCHEDSTATS is not set +# CONFIG_DEBUG_SLAB is not set +CONFIG_DEBUG_PREEMPT=y +# CONFIG_DEBUG_RT_MUTEXES is not set +# CONFIG_RT_MUTEX_TESTER is not set +# CONFIG_DEBUG_SPINLOCK is not set +# CONFIG_DEBUG_MUTEXES is not set +# CONFIG_DEBUG_RWSEMS is not set +# CONFIG_DEBUG_LOCK_ALLOC is not set +# CONFIG_PROVE_LOCKING is not set +# CONFIG_DEBUG_SPINLOCK_SLEEP is not set +# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set +# CONFIG_DEBUG_KOBJECT is not set +# CONFIG_DEBUG_INFO is not set +# CONFIG_DEBUG_VM is not set +# CONFIG_DEBUG_LIST is not set +CONFIG_FORCED_INLINING=y +# CONFIG_RCU_TORTURE_TEST is not set +CONFIG_CROSSCOMPILE=y +CONFIG_CMDLINE="" +# CONFIG_DEBUG_STACK_USAGE is not set +# CONFIG_KGDB is not set +# CONFIG_RUNTIME_DEBUG is not set +# CONFIG_MIPS_UNCACHED is not set + +# +# Security options +# +# CONFIG_KEYS is not set +# CONFIG_SECURITY is not set + +# +# Cryptographic options +# +CONFIG_CRYPTO=y +CONFIG_CRYPTO_ALGAPI=y +CONFIG_CRYPTO_BLKCIPHER=y +CONFIG_CRYPTO_HASH=y +CONFIG_CRYPTO_MANAGER=y +CONFIG_CRYPTO_HMAC=y +# CONFIG_CRYPTO_XCBC is not set +CONFIG_CRYPTO_NULL=y +# CONFIG_CRYPTO_MD4 is not set +CONFIG_CRYPTO_MD5=y +CONFIG_CRYPTO_SHA1=y +# CONFIG_CRYPTO_SHA256 is not set +# CONFIG_CRYPTO_SHA512 is not set +# CONFIG_CRYPTO_WP512 is not set +# CONFIG_CRYPTO_TGR192 is not set +# CONFIG_CRYPTO_GF128MUL is not set +CONFIG_CRYPTO_ECB=m +CONFIG_CRYPTO_CBC=y +# CONFIG_CRYPTO_LRW is not set +CONFIG_CRYPTO_DES=y +# CONFIG_CRYPTO_BLOWFISH is not set +# CONFIG_CRYPTO_TWOFISH is not set +# CONFIG_CRYPTO_SERPENT is not set +CONFIG_CRYPTO_AES=y +# CONFIG_CRYPTO_CAST5 is not set +# CONFIG_CRYPTO_CAST6 is not set +# CONFIG_CRYPTO_TEA is not set +# CONFIG_CRYPTO_ARC4 is not set +# CONFIG_CRYPTO_KHAZAD is not set +# CONFIG_CRYPTO_ANUBIS is not set +CONFIG_CRYPTO_DEFLATE=y +# CONFIG_CRYPTO_MICHAEL_MIC is not set +# CONFIG_CRYPTO_CRC32C is not set +# CONFIG_CRYPTO_TEST is not set + +# +# Hardware crypto devices +# + +# +# Library routines +# +CONFIG_BITREVERSE=y +# CONFIG_CRC_CCITT is not set +# CONFIG_CRC16 is not set +CONFIG_CRC32=y +# CONFIG_LIBCRC32C is not set +CONFIG_ZLIB_INFLATE=y +CONFIG_ZLIB_DEFLATE=y +CONFIG_PLIST=y +CONFIG_IOMAP_COPY=y diff --git a/arch/mips/kernel/head.S b/arch/mips/kernel/head.S index 9a7811d..f9f5551 100644 --- a/arch/mips/kernel/head.S +++ b/arch/mips/kernel/head.S @@ -130,10 +130,18 @@ #endif .endm /* + * Reserverd space not required for PMC boards, although we need to + * jump to kernel start. + */ +#ifdef CONFIG_PMC_MSP + jal kernel_entry +#else + /* * Reserved space for exception handlers. * Necessary for machines which link their kernels at KSEG0. */ .fill 0x400 +#endif /* CONFIG_PMC_MSP */ EXPORT(stext) # used for profiling EXPORT(_stext) diff --git a/arch/mips/kernel/traps.c b/arch/mips/kernel/traps.c index 2a932ca..e15a454 100644 --- a/arch/mips/kernel/traps.c +++ b/arch/mips/kernel/traps.c @@ -70,6 +70,7 @@ extern asmlinkage void handle_reserved(v extern int fpu_emulator_cop1Handler(struct pt_regs *xcp, struct mips_fpu_struct *ctx, int has_fpu); +void (*board_watchpoint_handler)(struct pt_regs *regs); void (*board_be_init)(void); int (*board_be_handler)(struct pt_regs *regs, int is_fixup); void (*board_nmi_handler_setup)(void); @@ -859,13 +860,17 @@ asmlinkage void do_mdmx(struct pt_regs * asmlinkage void do_watch(struct pt_regs *regs) { - /* - * We use the watch exception where available to detect stack - * overflows. - */ - dump_tlb_all(); - show_regs(regs); - panic("Caught WATCH exception - probably caused by stack overflow."); + if (board_watchpoint_handler) { + (*board_watchpoint_handler)(regs); + } else { + /* + * We use the watch exception where available to detect stack + * overflows. + */ + dump_tlb_all(); + show_regs(regs); + panic("Caught WATCH exception - probably caused by stack overflow."); + } } asmlinkage void do_mcheck(struct pt_regs *regs) diff --git a/include/asm-mips/bootinfo.h b/include/asm-mips/bootinfo.h index 8e321f5..6d27916 100644 --- a/include/asm-mips/bootinfo.h +++ b/include/asm-mips/bootinfo.h @@ -213,6 +213,18 @@ #define MACH_TITAN_EXCITE 2 /* Basler e #define MACH_GROUP_NEC_EMMA2RH 25 /* NEC EMMA2RH (was 23) */ #define MACH_NEC_MARKEINS 0 /* NEC EMMA2RH Mark-eins */ +/* + * Valid machtype for group PMC-MSP + */ +#define MACH_GROUP_MSP 23 /* PMC-Sierra MSP boards/CPUs */ +#define MACH_MSP4200_EVAL 0 /* PMC-Sierra MSP4200 Evaluation board */ +#define MACH_MSP4200_GW 1 /* PMC-Sierra MSP4200 Gateway demo board */ +#define MACH_MSP4200_FPGA 2 /* PMC-Sierra MSP4200 Emulation board */ +#define MACH_MSP7120_EVAL 3 /* PMC-Sierra MSP7120 Evaluation board */ +#define MACH_MSP7120_GW 4 /* PMC-Sierra MSP7120 Residential Gateway board */ +#define MACH_MSP7120_FPGA 5 /* PMC-Sierra MSP7120 Emulation board */ +#define MACH_MSP_OTHER 255 /* PMC-Sierra unknown board type */ + #define CL_SIZE COMMAND_LINE_SIZE const char *get_system_type(void); diff --git a/include/asm-mips/mipsregs.h b/include/asm-mips/mipsregs.h index 9985cb7..bd683b6 100644 --- a/include/asm-mips/mipsregs.h +++ b/include/asm-mips/mipsregs.h @@ -15,6 +15,7 @@ #define _ASM_MIPSREGS_H #include #include +#include /* * The following macros are especially useful for __asm__ @@ -1292,10 +1293,39 @@ static inline void tlb_probe(void) static inline void tlb_read(void) { +#if MIPS34K_MISSED_ITLB_WAR + int res = 0; + + __asm__ __volatile__( + " .set push \n" + " .set noreorder \n" + " .set noat \n" + " .set mips32r2 \n" + " .word 0x41610001 # dvpe $1 \n" + " move %0, $1 \n" + " ehb \n" + " .set pop \n" + : "=r" (res)); + + instruction_hazard(); +#endif + __asm__ __volatile__( ".set noreorder\n\t" "tlbr\n\t" ".set reorder"); + +#if MIPS34K_MISSED_ITLB_WAR + if ((res & _ULCAST_(1))) + __asm__ __volatile__( + " .set push \n" + " .set noreorder \n" + " .set noat \n" + " .set mips32r2 \n" + " .word 0x41600021 # evpe \n" + " ehb \n" + " .set pop \n"); +#endif } static inline void tlb_write_indexed(void) diff --git a/include/asm-mips/war.h b/include/asm-mips/war.h index 13a3502..74c08e6 100644 --- a/include/asm-mips/war.h +++ b/include/asm-mips/war.h @@ -196,6 +196,14 @@ #define R10000_LLSC_WAR 1 #endif /* + * 34K core erratum: "Problems Executing the TLBR Instruction" + */ +#if defined(CONFIG_PMC_MSP7120_EVAL) || defined(CONFIG_PMC_MSP7120_GW) || \ + defined(CONFIG_PMC_MSP7120_FPGA) +#define MIPS34K_MIS