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-Orcp