From owner-freebsd-arch@FreeBSD.ORG Sun Apr 22 22:25:39 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 37F4916A407 for ; Sun, 22 Apr 2007 22:25:39 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id ED8FF13C45E for ; Sun, 22 Apr 2007 22:25:38 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1133281pyh for ; Sun, 22 Apr 2007 15:25:38 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type:content-transfer-encoding:content-disposition; b=m9LaQg11pXWpxEnDcCO63l+ZaDk+iL/rQ5h1RJ+01kePBoaC5/GEBGAr+SAobGapEyCTqA1fWqQ8StjeFPk6kBtPp879JZsmf18n1KIkE59Mjv0oF1qP+g0CYSNM8dVk2z3og14Hab4TywpG0Qndl8wP0clJGSXK5av4/DfoB6c= 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=px4zOP4MFrNrqPyXrec2u1i6xDTLrtnkIoPbT1M9ZkxTOEi+MrQJw6R+KZwjozJYmao0VqO7h5T1l/ecxbhtgrXhRn3hNk6jgoSRYXGhpsl09r8xPIilmUIK9Xi+WqT6kViBgfnfTi0P0V7fsAd5BZeVz8d4F2TelT0G3tOr2+w= Received: by 10.35.98.3 with SMTP id a3mr9733244pym.1177279110991; Sun, 22 Apr 2007 14:58:30 -0700 (PDT) Received: by 10.35.54.15 with HTTP; Sun, 22 Apr 2007 14:58:30 -0700 (PDT) Message-ID: Date: Sun, 22 Apr 2007 14:58:30 -0700 From: "Howard Su" To: "Pawel Jakub Dawidek" , arch@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Cc: Subject: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 Apr 2007 22:25:39 -0000 When I working on tmpfs privilege, I need copy a lot of privilege check code from UFS. I suppose there is same problem in ZFS. So moving this sort of privilege code into VFS will reduce a lot of duplicate code and also make fs implementation simple and consistent in security thing. Besides that, some quota/extattr feature can be also implement in VFS layer. I suppose the fact today that a lot of stuffs are UFS related is because we have VFS after UFS. So VFS only abstracts the common stuffs for a misc file system like iso/udf/msdosfs. We didn't suppose we will have more full-featured file system besides UFS. (NFS has its own & different implementation about security.) Does VFS have other design goal that I am not aware to preventing us moving more shared code into it? -- -Howard From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 12:13:23 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C8BD316A40A for ; Mon, 23 Apr 2007 12:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from relay01.kiev.sovam.com (relay01.kiev.sovam.com [62.64.120.200]) by mx1.freebsd.org (Postfix) with ESMTP id 60EE813C45E for ; Mon, 23 Apr 2007 12:13:23 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from [212.82.216.227] (helo=fw.zoral.com.ua) by relay01.kiev.sovam.com with esmtps (TLSv1:AES256-SHA:256) (Exim 4.60) (envelope-from ) id 1Hfx4F-000NV5-Bm; Mon, 23 Apr 2007 14:50:52 +0300 Received: from deviant.kiev.zoral.com.ua (root@deviant.kiev.zoral.com.ua [10.1.1.148]) by fw.zoral.com.ua (8.13.4/8.13.4) with ESMTP id l3NBojH8027264 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Mon, 23 Apr 2007 14:50:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: from deviant.kiev.zoral.com.ua (kostik@localhost [127.0.0.1]) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1) with ESMTP id l3NBojTv022869; Mon, 23 Apr 2007 14:50:45 +0300 (EEST) (envelope-from kostikbel@gmail.com) Received: (from kostik@localhost) by deviant.kiev.zoral.com.ua (8.14.1/8.14.1/Submit) id l3NBogef022868; Mon, 23 Apr 2007 14:50:42 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: deviant.kiev.zoral.com.ua: kostik set sender to kostikbel@gmail.com using -f Date: Mon, 23 Apr 2007 14:50:42 +0300 From: Kostik Belousov To: Howard Su Message-ID: <20070423115042.GF2052@deviant.kiev.zoral.com.ua> References: Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="ZRyEpB+iJ+qUx0kp" Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.2i X-Virus-Scanned: ClamAV version 0.88.7, clamav-milter version 0.88.7 on fw.zoral.com.ua X-Virus-Status: Clean X-Spam-Status: No, score=-0.1 required=5.0 tests=ALL_TRUSTED,SPF_NEUTRAL autolearn=failed version=3.1.8 X-Spam-Checker-Version: SpamAssassin 3.1.8 (2007-02-13) on fw.zoral.com.ua X-Scanner-Signature: a96565856d7d777f03ae631b61e05b17 X-DrWeb-checked: yes X-SpamTest-Envelope-From: kostikbel@gmail.com X-SpamTest-Group-ID: 00000000 X-SpamTest-Info: Profiles 972 [Apr 23 2007] X-SpamTest-Info: helo_type=3 X-SpamTest-Info: {received from trusted relay: not dialup} X-SpamTest-Method: none X-SpamTest-Method: Local Lists X-SpamTest-Rate: 0 X-SpamTest-Status: Not detected X-SpamTest-Status-Extended: not_detected X-SpamTest-Version: SMTP-Filter Version 3.0.0 [0255], KAS30/Release Cc: arch@freebsd.org, Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 12:13:23 -0000 --ZRyEpB+iJ+qUx0kp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Apr 22, 2007 at 02:58:30PM -0700, Howard Su wrote: > When I working on tmpfs privilege, I need copy a lot of privilege > check code from UFS. I suppose there is same problem in ZFS. So moving > this sort of privilege code into VFS will reduce a lot of duplicate > code and also make fs implementation simple and consistent in security > thing. >=20 > Besides that, some quota/extattr feature can be also implement in VFS lay= er. Quota code (ufs/ufs/ufs_quota.c) is mostly filesystem-independent, it only require particular format for the quota file, and several fields in the ufs mount structure, as well as ufs mount interlock. The later could be factored-out quite easily. On the other hand, only ufs is stuffed with hooks for the quota handling. > I suppose the fact today that a lot of stuffs are UFS related is > because we have VFS after UFS. So VFS only abstracts the common stuffs > for a misc file system like iso/udf/msdosfs. We didn't suppose we will > have more full-featured file system besides UFS. (NFS has its own & > different implementation about security.) >=20 > Does VFS have other design goal that I am not aware to preventing us > moving more shared code into it? I would let others comment on the feasibility of factoring out permission check code. What I want to point out is that some time ago UFS itself was considered as layer with underlying implementation providing the actual structure for the storage. At least two such implementations existed, FFS and LFS. The LFS is long dead and removed from CVS. All that left from the layering is several method pointers in struct ufsmount. I suspect that current code has eroded the border between UFS and FFS. That said, I'm not sure whether implementing tmpfs as some TMPFS under UFS layer is possible now, but you may look at this. --ZRyEpB+iJ+qUx0kp Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (FreeBSD) iD8DBQFGLJ2SC3+MBN1Mb4gRAqU9AJ92Mk4kvJjEjqOAjaOecvzsNADOIwCfX+8z SHEMG/asdtfqje0f/7fuhAs= =6TKx -----END PGP SIGNATURE----- --ZRyEpB+iJ+qUx0kp-- From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 12:22:19 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D630116A404; Mon, 23 Apr 2007 12:22:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id AFA8813C4B0; Mon, 23 Apr 2007 12:22:19 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id 29E9046B80; Mon, 23 Apr 2007 08:22:19 -0400 (EDT) Date: Mon, 23 Apr 2007 13:22:19 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Howard Su In-Reply-To: Message-ID: <20070423132006.T26224@fledge.watson.org> References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 12:22:19 -0000 On Sun, 22 Apr 2007, Howard Su wrote: > When I working on tmpfs privilege, I need copy a lot of privilege check code > from UFS. I suppose there is same problem in ZFS. So moving this sort of > privilege code into VFS will reduce a lot of duplicate code and also make fs > implementation simple and consistent in security thing. > > Besides that, some quota/extattr feature can be also implement in VFS layer. > > I suppose the fact today that a lot of stuffs are UFS related is because we > have VFS after UFS. So VFS only abstracts the common stuffs for a misc file > system like iso/udf/msdosfs. We didn't suppose we will have more > full-featured file system besides UFS. (NFS has its own & different > implementation about security.) > > Does VFS have other design goal that I am not aware to preventing us moving > more shared code into it? Pawel and I have talked about this a bit in the past -- vaccess(9) and vaccess_acl_posix1e(9) were really the first step in abstracting file system access control decisions, and aren't a bad step -- they certainly cover a lot of the previously plentifully replicated cases (countless foo_access() VOP implementations). However, I think we should be restrained and do a bit of experimentation -- sometimes as much work could be done bundling up the common arguments to deliver them to a central access check as is done in having the access check appear in the calling code itself. Can we refine VOP_ACCESS() a bit further to get what we need, or do we need new common functions? Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 16:11:59 2007 Return-Path: X-Original-To: freebsd-arch@FreeBSD.org Delivered-To: freebsd-arch@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 01E1116A406 for ; Mon, 23 Apr 2007 16:11:59 +0000 (UTC) (envelope-from vikasrami@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.230]) by mx1.freebsd.org (Postfix) with ESMTP id B0CB113C48A for ; Mon, 23 Apr 2007 16:11:58 +0000 (UTC) (envelope-from vikasrami@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1375826nza for ; Mon, 23 Apr 2007 09:11:57 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:mime-version:content-type; b=tGe2AHK3ixVEDh1i5os2ukaaLXj8B02PZwLHIdyG5yp1iyBtBd4Llnks6qjIOggyHUsD1BZAWtUgX/u1L2R+niJpJdBOQWvifTkcdzMpyyVPUjPiQHlk+q9+L7nfdKGjOpt3VfR+NbhjVDy1b6LIqmsTj1/1QPmEh5PzrOv6qZw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:mime-version:content-type; b=HI3fppBXem/fUal2ylNE1hUAmY6kTiJ/y66YW546bFoFXUUF2IF6dAufWk7D4zWoMVXU3hQAffdkdCTOcd0U456nT7RK6tA/VTYDcs1lBOw7i5nH4NS26SYRr07FmiehQEw+GpE4NJ4SFZ8yLlrL26+PLLgGS3Kl11lCATrMw+o= Received: by 10.114.159.1 with SMTP id h1mr2569886wae.1177343010248; Mon, 23 Apr 2007 08:43:30 -0700 (PDT) Received: by 10.114.81.2 with HTTP; Mon, 23 Apr 2007 08:43:30 -0700 (PDT) Message-ID: Date: Mon, 23 Apr 2007 21:13:30 +0530 From: "Vikas Rami" To: freebsd-arch@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: Subject: Intel Installtion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 16:11:59 -0000 Hello Friend, I have a PIII Processor, which version of FreeBSD is suitable for my machine. -- Regards Vikas Rami Cell No. +91-9323208604 "Don't tell GOD how big your problems are... tell your problems how big your GOD is" Keep Smiling From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 23:22:35 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 69B1216A40B for ; Mon, 23 Apr 2007 23:22:35 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.178]) by mx1.freebsd.org (Postfix) with ESMTP id 16F1E13C46C for ; Mon, 23 Apr 2007 23:22:34 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1397884pyh for ; Mon, 23 Apr 2007 16:22:34 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=NUKK1MDJl58pv/07cd7XMz5v+LUXcs1xZ29Df/VXvyTdZDDaQJy1np6hpFjdqkHi1pbnLy2MIC43slAjhKwZV87+v6kwYRIAupDtv1hLGq57TnUW0Un9oIHrWThbJ9NUnlbbQfYH2CMRY4IVrFuhL8ouniTb1387PXMJcamC/vc= 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=OARrSMNSZ51GI86Z6YKTKP1MMG10KfCbCH61ct4G0oBxNPMsRFBDydonCIuydF3UceK3xJiZcrr4WD9GWenfn0inhQ2G0VDFAzWf4ovv3lmE05CE92IYu1iN0FEOILFe9Xn/Wk9ATOtoRBAQK8gKI2wPgOz0szMmCP0drqKneoE= Received: by 10.64.184.16 with SMTP id h16mr12962850qbf.1177370552986; Mon, 23 Apr 2007 16:22:32 -0700 (PDT) Received: by 10.35.54.15 with HTTP; Mon, 23 Apr 2007 16:22:32 -0700 (PDT) Message-ID: Date: Mon, 23 Apr 2007 16:22:32 -0700 From: "Howard Su" To: "Robert Watson" In-Reply-To: <20070423132006.T26224@fledge.watson.org> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070423132006.T26224@fledge.watson.org> Cc: arch@freebsd.org, Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 23:22:35 -0000 On 4/23/07, Robert Watson wrote: > > > Pawel and I have talked about this a bit in the past -- vaccess(9) and > vaccess_acl_posix1e(9) were really the first step in abstracting file system > access control decisions, and aren't a bad step -- they certainly cover a lot > of the previously plentifully replicated cases (countless foo_access() VOP > implementations). However, I think we should be restrained and do a bit of > experimentation -- sometimes as much work could be done bundling up the common > arguments to deliver them to a central access check as is done in having the > access check appear in the calling code itself. Can we refine VOP_ACCESS() a > bit further to get what we need, or do we need new common functions? > In FS dependent code, we don't only call VOP_ACCESS, but also check some flags like ISUID, ISGID, NOUNLINK, APPEND, etc. This sort of stuffs are so easy to regerssion when I work on tmpfs and it should be almost same code in all the FS. However VFS don't have this sort of information in vnode structure. Is this can be added? -- -Howard From owner-freebsd-arch@FreeBSD.ORG Mon Apr 23 23:25:43 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id D84C416A404 for ; Mon, 23 Apr 2007 23:25:43 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: from py-out-1112.google.com (py-out-1112.google.com [64.233.166.183]) by mx1.freebsd.org (Postfix) with ESMTP id 8646513C45D for ; Mon, 23 Apr 2007 23:25:43 +0000 (UTC) (envelope-from howard0su@gmail.com) Received: by py-out-1112.google.com with SMTP id f31so1398577pyh for ; Mon, 23 Apr 2007 16:25:43 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=q5R8TSubJLkmF0jABuKej9VCaCteRO+ei0lVaMMo+HFHStQcPdhgV53iueVwLK3RqJjWPWdpSrF5kr90/4dH854h2kbUCXL3ft1RtpEGePVu34cdHlOdrT1fRsFA41QxFjCJvesvEPCQJWPEfAWV3TXNRr+x1lPlJ9B1FDUS++I= 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=P/iD+SXdOF03GNZ8duliP8Cp2et7Kf3BoaIW7g5N8LIFtgCdoGjlYp0g+YHA36Fugp5I4Ab87lhixgWHNjolhlCQmXis6K1VrJpqgJUgOX/vzQiXV8G5AIURl4OHvlX9Tf5KywcXaZpRw0rGal7GT6mvm5PdpZzNyvmOV/dbEEE= Received: by 10.35.111.14 with SMTP id o14mr11860868pym.1177370742902; Mon, 23 Apr 2007 16:25:42 -0700 (PDT) Received: by 10.35.54.15 with HTTP; Mon, 23 Apr 2007 16:25:42 -0700 (PDT) Message-ID: Date: Mon, 23 Apr 2007 16:25:42 -0700 From: "Howard Su" To: "Kostik Belousov" In-Reply-To: <20070423115042.GF2052@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20070423115042.GF2052@deviant.kiev.zoral.com.ua> Cc: arch@freebsd.org, Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 23 Apr 2007 23:25:43 -0000 On 4/23/07, Kostik Belousov wrote: > On Sun, Apr 22, 2007 at 02:58:30PM -0700, Howard Su wrote: > Quota code (ufs/ufs/ufs_quota.c) is mostly filesystem-independent, it > only require particular format for the quota file, and several fields in > the ufs mount structure, as well as ufs mount interlock. The later could be > factored-out quite easily. > > On the other hand, only ufs is stuffed with hooks for the quota handling. I agree that current implementation is FS-depend. However in theory, nothing prevent you to store quota data in another FS even. We only need some API calls which expose through VFS like AllocateQuota, FreeQuota, CheckQuota. The storage part can be hide by VFS. Anyway, this is my dream. No prototyping prove it yet. > > > I would let others comment on the feasibility of factoring out permission > check code. > > What I want to point out is that some time ago UFS itself was considered > as layer with underlying implementation providing the actual structure > for the storage. At least two such implementations existed, FFS and > LFS. The LFS is long dead and removed from CVS. All that left from the > layering is several method pointers in struct ufsmount. I suspect that > current code has eroded the border between UFS and FFS. That said, I'm > not sure whether implementing tmpfs as some TMPFS under UFS layer is > possible now, but you may look at this. > Glad to know some old stuffs. Very helpful. -- -Howard From owner-freebsd-arch@FreeBSD.ORG Tue Apr 24 03:40:53 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C677316A400 for ; Tue, 24 Apr 2007 03:40:53 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.224]) by mx1.freebsd.org (Postfix) with ESMTP id 8647E13C459 for ; Tue, 24 Apr 2007 03:40:53 +0000 (UTC) (envelope-from joseph.koshy@gmail.com) Received: by nz-out-0506.google.com with SMTP id r28so1549840nza for ; Mon, 23 Apr 2007 20:40:52 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=saBP5RclHFNRoL48GkHdllvJXEk2gPfnv3MAuJ1MxmjolJKO67XMeapdHiUCZlbciN9jZY8TMj9piLJCv9xgUfSKEW4SgETiJkfkO3rPkIJdOoD0Ovg8SbqH+bgyDiV4ugXvpZOLEwkWr3JqbHNVbjV9beYqmdSqfLLd3+h457Y= 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=OD+s9rH6/AFyP6Un/ESffKvYihh4cG7xabdWfzPOBTh9qMiNOmW2B8tB7+NYjkUb0KljxAkQbiNHdSvCm6wqFUDKaxzJw36IdHB3zC3YuK/OzzCaf/9n5S5WXOGGO81lO77XILs4w+TOmJpQWLr2E24wdlOm3i8VhgvlYQCsGYk= Received: by 10.65.240.17 with SMTP id s17mr13289416qbr.1177384470404; Mon, 23 Apr 2007 20:14:30 -0700 (PDT) Received: by 10.65.83.17 with HTTP; Mon, 23 Apr 2007 20:14:30 -0700 (PDT) Message-ID: <84dead720704232014g63064e1am380dfdda9621c666@mail.gmail.com> Date: Tue, 24 Apr 2007 08:44:30 +0530 From: "Joseph Koshy" To: "Vikas Rami" 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: Cc: freebsd-arch@freebsd.org Subject: Re: Intel Installtion X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 03:40:53 -0000 > I have a PIII Processor, which version of FreeBSD is > suitable for my machine. This is the wrong mailing list for this kind of question. freebsd-arch@ is for discussing architectural issues in FreeBSD. You should try freebsd-questions@. That said, the current released version of FreeBSD (6.2) runs just fine on PIII machines. -- FreeBSD Volunteer, http://people.freebsd.org/~jkoshy From owner-freebsd-arch@FreeBSD.ORG Tue Apr 24 08:11:40 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 40E3D16A400; Tue, 24 Apr 2007 08:11:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 1737413C45B; Tue, 24 Apr 2007 08:11:40 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A6FBF476BA; Tue, 24 Apr 2007 04:11:39 -0400 (EDT) Date: Tue, 24 Apr 2007 09:11:39 +0100 (BST) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: Howard Su In-Reply-To: Message-ID: <20070424090943.X52872@fledge.watson.org> References: <20070423132006.T26224@fledge.watson.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: arch@freebsd.org, Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 08:11:40 -0000 On Mon, 23 Apr 2007, Howard Su wrote: > On 4/23/07, Robert Watson wrote: >> >> Pawel and I have talked about this a bit in the past -- vaccess(9) and >> vaccess_acl_posix1e(9) were really the first step in abstracting file >> system access control decisions, and aren't a bad step -- they certainly >> cover a lot of the previously plentifully replicated cases (countless >> foo_access() VOP implementations). However, I think we should be >> restrained and do a bit of experimentation -- sometimes as much work could >> be done bundling up the common arguments to deliver them to a central >> access check as is done in having the access check appear in the calling >> code itself. Can we refine VOP_ACCESS() a bit further to get what we need, >> or do we need new common functions? > > In FS dependent code, we don't only call VOP_ACCESS, but also check some > flags like ISUID, ISGID, NOUNLINK, APPEND, etc. This sort of stuffs are so > easy to regerssion when I work on tmpfs and it should be almost same code in > all the FS. However VFS don't have this sort of information in vnode > structure. Is this can be added? I don't think I would add these to the vnode -- remember that, for distributed file systems, these fields may change asynchronously, and that for at least one critical distributed file system (NFS) there is no asynchronous notification facility from the server. I like the vaccess() approach, in which the file system is responsible for determining the values of any relevant fields, and passing them into what is effectively a library routine that performs the check. This avoids having these access control checks perform VOP's, which has significant overhead, and allows the file system to optimize storage/retrieval of these volatile fields. Robert N M Watson Computer Laboratory University of Cambridge From owner-freebsd-arch@FreeBSD.ORG Tue Apr 24 08:19:29 2007 Return-Path: X-Original-To: arch@freebsd.org Delivered-To: freebsd-arch@FreeBSD.ORG Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id A19C416A46E; Tue, 24 Apr 2007 08:19:29 +0000 (UTC) (envelope-from SRS0+0d542715679c15f37660+1339+infradead.org+hch@pentafluge.srs.infradead.org) Received: from pentafluge.infradead.org (pentafluge.infradead.org [213.146.154.40]) by mx1.freebsd.org (Postfix) with ESMTP id 644C213C484; Tue, 24 Apr 2007 08:19:29 +0000 (UTC) (envelope-from SRS0+0d542715679c15f37660+1339+infradead.org+hch@pentafluge.srs.infradead.org) Received: from hch by pentafluge.infradead.org with local (Exim 4.63 #1 (Red Hat Linux)) id 1HgFwA-0005hm-BB; Tue, 24 Apr 2007 08:59:46 +0100 Date: Tue, 24 Apr 2007 08:59:46 +0100 From: Christoph Hellwig To: Howard Su Message-ID: <20070424075946.GA20864@infradead.org> References: <20070423132006.T26224@fledge.watson.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 X-SRS-Rewrite: SMTP reverse-path rewritten from by pentafluge.infradead.org See http://www.infradead.org/rpr.html Cc: arch@freebsd.org, Robert Watson , Pawel Jakub Dawidek Subject: Re: move audit/priviliage check into VFS X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 24 Apr 2007 08:19:29 -0000 On Mon, Apr 23, 2007 at 04:22:32PM -0700, Howard Su wrote: > >access check appear in the calling code itself. Can we refine > >VOP_ACCESS() a > >bit further to get what we need, or do we need new common functions? > > > In FS dependent code, we don't only call VOP_ACCESS, but also check > some flags like ISUID, ISGID, NOUNLINK, APPEND, etc. This sort of > stuffs are so easy to regerssion when I work on tmpfs and it should be > almost same code in all the FS. However VFS don't have this sort of > information in vnode structure. Is this can be added? You might want to look a little at the Linux approach. As a start do a mental s/permission/access/ because linux calls the routine to do permissions checks *permission* not *access*/*ACCESS*/. At the highest level there is a permission() routine in generic code, which does all checks that are not specific to a security model, like denying write requests to ro mounts or immutable files, and then hands down into the filesystem permission routine. For the filesystem permission routines there's a generic one again for the typical unix filesystem that performs all the remaining classic unix permission check semantics. Now in Linux this is a little easier because we store a lot more information in the generic inode (aka your vnode), but with a VOP_GETATTR thrown in you could probably do something similar. From owner-freebsd-arch@FreeBSD.ORG Fri Apr 27 19:34:23 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7333316A407; Fri, 27 Apr 2007 19:34:23 +0000 (UTC) (envelope-from hselasky@freebsd.org) Received: from swip.net (mailfe13.swip.net [212.247.155.129]) by mx1.freebsd.org (Postfix) with ESMTP id 600C913C46C; Fri, 27 Apr 2007 19:34:22 +0000 (UTC) (envelope-from hselasky@freebsd.org) X-Cloudmark-Score: 0.000000 [] Received: from [193.71.38.142] (account mc467741@c2i.net HELO [10.42.11.147]) by mailfe13.swip.net (CommuniGate Pro SMTP 5.1.7) with ESMTPA id 83177350; Fri, 27 Apr 2007 20:32:38 +0200 From: Hans Petter Selasky To: freebsd-hackers@freebsd.org Date: Fri, 27 Apr 2007 20:32:20 +0200 User-Agent: KMail/1.9.5 References: <200704262136.33196.hselasky@c2i.net> <200704271917.29939.hselasky@freebsd.org> <46323A77.8010907@elischer.org> In-Reply-To: <46323A77.8010907@elischer.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200704272032.20664.hselasky@freebsd.org> Cc: Daniel Eischen , Attilio Rao , Julian Elischer , freebsd-arch@freebsd.org Subject: Re: msleep() on recursivly locked mutexes X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 27 Apr 2007 19:34:23 -0000 On Friday 27 April 2007 20:01, Julian Elischer wrote: > Hans Petter Selasky wrote: > > First of all: Where is FreeBSD's locking strategy document? > > It is just started.. > man 9 locking. it needs a lot of work still. Excellent. > > > We should have a > > global strategy when we write device drivers, so that various modules can > > be connected together without races and locking order reversals. > > > > In my view there are two categories of mutexes. > > > > 1) Global mutexes. > > > > 2) Private mutexes. > > > > Rule: The Global mutex is locked last. > > errr I'm not sure I'm following but this sounds kind-of reversed from > normal behaviour. Yes, it is. But you have to make a choice. Either this way or the other way. But not both! The reason for my choice is that I consider it to be more complicated to be a Global device than a private device. Complicated means that the Global device, which is locked last, has to unlock its lock before it calls back the "private" device, like I have explained below. Hence there are fewer Global devices (e.g. USB host controllers), then private devices (USB device drivers), we end up with less code/headache locking the Global devices last. If that is unclear I can explain more. > > > How do we organize this. > > > > 1a) The global mutex protects interrupts/callbacks into a hardware > > driver. This is the lowest level. > > > > 2a) Private mutexes protects sub-devices of the hardware driver. This > > might be as simple as an IF-QUEUE. > > I'm having trouble following already. > you mean subcomponents? Yes, children of devices. Sub-devices. > > > I have chosen the following model: > > > > P0 indicates process 0. P1 indicates an optional second process. > > > > Up-call: > > > > P0 lock(2); > > P0 lock(1); The work done [here] might be to setup DMA-able memory, and link it into the hardware. > > P0 unlock(1); > > P0 unlock(2); > > this looks "interesting". > Can you give a more concrete example of this? > what work is done in the upcall? WHo is upcalling to who? For example an USB device driver might be up-calling to the USB host controller driver. Down call is when the transfer finishes. > > > Down-call: > > > > P1 lock(1); > > P1 wakeup P0 // for example > > P1 unlock(1); > > pretty normal. > > > P0 //callback: > > P0 lock(2); // the new USB stack currently uses P1 here > > P0 unlock(2); > > > > > > > > Sure, in the up-call you lock #2 longer than lock #1, that is why lock #1 > > has got to be a short as possible. But it does not make sense to make > > lock #2 lock shorter than lock #1. I cannot see that the system will go > > faster that way. > > > > In the downcall I see no problems at all. #1 does its things as fast as > > possible. In parallell #2 can still execute, until the "callback". > > > > I hope you understand my semantics. > > > > What do you want to change from what I have explained? > > > > Any comments? > > > > My conclusion: If you want more paralellism, then use more mutexes. Don't > > try to push an existing mutex by unlocking it! > > that may or may not be true depending on how busy the mutex is.. > but I don't think there is an argument about this. > > > shouldn't this be somewhere other than "hackers"? I've CC'ed freebsd-arch. --HPS From owner-freebsd-arch@FreeBSD.ORG Sat Apr 28 17:16:03 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 836C616A400 for ; Sat, 28 Apr 2007 17:16:03 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp12.mail.ogk.yahoo.co.jp (ybbsmtp12.mail.ogk.yahoo.co.jp [124.83.153.132]) by mx1.freebsd.org (Postfix) with SMTP id 17D9413C458 for ; Sat, 28 Apr 2007 17:16:02 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 825 invoked by alias); 28 Apr 2007 16:49:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; b=P4OdQ8zH1aKPb5xQRd3+EXd5dThHC1egiTbvHyk8zU29L0V2m9+kihTtUilB1AnUHEyCduR0LlIe5WYTuG+2HX8qA0z1WmtEc0kPoX7qcql+LHPdt6LJMqAhkoRmTW+J ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp12.mail.ogk.yahoo.co.jp with SMTP; 28 Apr 2007 16:49:21 -0000 X-Apparently-From: Message-ID: <46337B06.9080102@ybb.ne.jp> Date: Sun, 29 Apr 2007 01:49:10 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-arch@freebsd.org Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: ichwd for ICH8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2007 17:16:03 -0000 Hi, I am trying to port ichwd to ICH6 and later. I have a box which has ICH8 compliant mother board(GIGA BYTE GA-965P-DS3). As far as I refer the manual(Intel I/O Controller Hub 8 (ICH8) Family) , this driver can setup counter properly and then enable watchdog facility. But the driver can not make the system reboot when watchdog fire the interrupt. I can not figure out the reason of this problem is caused by my patch or current ichwd part. Because I do not have the box which have ICH5 or before. Does anyone use ichwd? diff -Nupr ichwd.orig/ichwd.c ichwd/ichwd.c --- ichwd.orig/ichwd.c Wed Apr 25 22:03:16 2007 +++ ichwd/ichwd.c Fri Apr 27 00:59:16 2007 @@ -71,20 +71,27 @@ __FBSDID("$FreeBSD: src/sys/dev/ichwd/ic #include static struct ichwd_device ichwd_devices[] = { - { VENDORID_INTEL, DEVICEID_82801AA, "Intel 82801AA watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801AB, "Intel 82801AB watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801BA, "Intel 82801BA watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801BAM, "Intel 82801BAM watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801CA, "Intel 82801CA watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801CAM, "Intel 82801CAM watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801DB, "Intel 82801DB watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801DBM, "Intel 82801DBM watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801E, "Intel 82801E watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801EBR, "Intel 82801EB/ER watchdog timer" }, - { VENDORID_INTEL, DEVICEID_82801FBR, "Intel 82801FB/FR watchdog timer" }, - { VENDORID_INTEL, DEVICEID_ICH5, "Intel ICH5 watchdog timer"}, - { VENDORID_INTEL, DEVICEID_6300ESB, "Intel 6300ESB watchdog timer"}, - { 0, 0, NULL }, + { VENDORID_INTEL, DEVICEID_82801AA, "Intel 82801AA watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801AB, "Intel 82801AB watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801BA, "Intel 82801BA watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801BAM, "Intel 82801BAM watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801CA, "Intel 82801CA watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801CAM, "Intel 82801CAM watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801DB, "Intel 82801DB watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801DBM, "Intel 82801DBM watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801E, "Intel 82801E watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801EBR, "Intel 82801EB/ER watchdog timer", 1} , + { VENDORID_INTEL, DEVICEID_82801FBR, "Intel 82801FB/FR watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH5, "Intel ICH5 watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_6300ESB, "Intel 6300ESB watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH6M, "Intel ICH6M watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH6W, "Intel ICH6W watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH7M, "Intel ICH7M watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH7MDH, "Intel ICH7MDH watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH8, "Intel ICH8 watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH8DH, "Intel ICH8DH watchdog timer", 2} , + { VENDORID_INTEL, DEVICEID_ICH8DO, "Intel ICH8DO watchdog timer", 2} , + { 0, 0, NULL, 0 } , }; static devclass_t ichwd_devclass; @@ -103,11 +110,21 @@ static devclass_t ichwd_devclass; #define ichwd_write_tco_4(sc, off, val) \ bus_space_write_4((sc)->tco_bst, (sc)->tco_bsh, (off), (val)) -#define ichwd_read_smi_4(sc, off) \ +#define ichwd_read_smi_4(sc, off) \ bus_space_read_4((sc)->smi_bst, (sc)->smi_bsh, (off)) #define ichwd_write_smi_4(sc, off, val) \ bus_space_write_4((sc)->smi_bst, (sc)->smi_bsh, (off), (val)) +#define ichwd_read_gcs_4(sc, off) \ + bus_read_4((sc)->gcs_res, (off)) +#define ichwd_write_gcs_4(sc, off, val) \ + bus_write_4((sc)->gcs_res, (off), (val)) + +#define ichwd_verbose_printf(dev,fmt,arg...) do { \ + if (bootverbose) \ + device_printf(dev, fmt, ##arg); \ + } while (0) + static __inline void ichwd_intr_enable(struct ichwd_softc *sc) { @@ -136,8 +153,7 @@ ichwd_tmr_enable(struct ichwd_softc *sc) cnt = ichwd_read_tco_2(sc, TCO1_CNT) & TCO_CNT_PRESERVE; ichwd_write_tco_2(sc, TCO1_CNT, cnt & ~TCO_TMR_HALT); sc->active = 1; - if (bootverbose) - device_printf(sc->device, "timer enabled\n"); + ichwd_verbose_printf(sc->device, "timer enabled\n"); } static __inline void @@ -148,25 +164,67 @@ ichwd_tmr_disable(struct ichwd_softc *sc cnt = ichwd_read_tco_2(sc, TCO1_CNT) & TCO_CNT_PRESERVE; ichwd_write_tco_2(sc, TCO1_CNT, cnt | TCO_TMR_HALT); sc->active = 0; - if (bootverbose) - device_printf(sc->device, "timer disabled\n"); + ichwd_verbose_printf(sc->device, "timer disabled\n"); } static __inline void ichwd_tmr_reload(struct ichwd_softc *sc) { - ichwd_write_tco_1(sc, TCO_RLD, 1); - if (bootverbose) - device_printf(sc->device, "timer reloaded\n"); + if (sc->tco_version == 1) + ichwd_write_tco_1(sc, TCO_RLD, 1); + else + ichwd_write_tco_2(sc, TCO_RLD, 1); + + ichwd_verbose_printf(sc->device, "timer reloaded\n"); } static __inline void ichwd_tmr_set(struct ichwd_softc *sc, uint8_t timeout) { - ichwd_write_tco_1(sc, TCO_TMR, timeout); + + if (sc->tco_version == 1) { + ichwd_write_tco_1(sc, TCO_TMR, timeout); + } else { + uint16_t tmr_val = ichwd_read_tco_2(sc, TCO_V2_TMR); + + tmr_val &= 0xfc00; + tmr_val |= timeout; + ichwd_write_tco_2(sc, TCO_V2_TMR, tmr_val); + } + sc->timeout = timeout; - if (bootverbose) - device_printf(sc->device, "timeout set to %u ticks\n", timeout); + + ichwd_verbose_printf(sc->device, "timeout set to %u ticks\n", timeout); +} + +static __inline int +ichwd_clear_noreboot(struct ichwd_softc *sc) +{ + uint32_t status; + int rc = 0; + + /* try to clear the NO_REBOOT bit */ + if (sc->tco_version == 1) { + pci_write_config(sc->ich, ICH_GEN_STA, 0x00, 1); + status = pci_read_config(sc->ich, ICH_GEN_STA, 1); + if (status & ICH_GEN_STA_NO_REBOOT) + rc = EIO; + } else { + status = ichwd_read_gcs_4(sc, 0); + status &= ~(GCS_NOREBOOT); + ichwd_write_gcs_4(sc, 0, status); + + status = ichwd_read_gcs_4(sc, 0); + if (status & GCS_NOREBOOT) + rc = EIO; + } + + if (rc) + ichwd_verbose_printf(sc->device, + "%s(): ICH WDT present but disabled\n", + __func__); + + return rc; } /* @@ -197,7 +255,24 @@ ichwd_event(void *arg, unsigned int cmd, } } -static unsigned int pmbase = 0; +static device_t +ichwd_find_ich_lpc_bridge(struct ichwd_device **id_p) { + struct ichwd_device *id; + device_t ich = NULL; + + /* look for an ICH LPC interface bridge */ + for (id = ichwd_devices; id->desc != NULL; ++id) + if ((ich = pci_find_device(id->vendor, id->device)) != NULL) + break; + + if ( (bootverbose) && (ich) ) + printf("%s(): found ICH chipset: %s TCO version:%d\n", __func__, id->desc, id->version); + + if (id_p) + *id_p = id; + + return ich; +} /* * Look for an ICH LPC interface bridge. If one is found, register an @@ -206,44 +281,33 @@ static unsigned int pmbase = 0; static void ichwd_identify(driver_t *driver, device_t parent) { - struct ichwd_device *id; + struct ichwd_device *id_p; device_t ich = NULL; device_t dev; + uint32_t rcba; + int rc; - /* look for an ICH LPC interface bridge */ - for (id = ichwd_devices; id->desc != NULL; ++id) - if ((ich = pci_find_device(id->vendor, id->device)) != NULL) - break; + ich = ichwd_find_ich_lpc_bridge(&id_p); if (ich == NULL) return; - if (bootverbose) - printf("%s(): found ICH chipset: %s\n", __func__, id->desc); - - /* get for ACPI base address */ - pmbase = pci_read_config(ich, ICH_PMBASE, 2) & ICH_PMBASE_MASK; - if (pmbase == 0) { - if (bootverbose) - printf("%s(): ICH PMBASE register is empty\n", - __func__); - return; - } - - /* try to clear the NO_REBOOT bit */ - pci_write_config(ich, ICH_GEN_STA, 0x00, 1); - if (pci_read_config(ich, ICH_GEN_STA, 1) & ICH_GEN_STA_NO_REBOOT) { - if (bootverbose) - printf("%s(): ICH WDT present but disabled\n", - __func__); - return; - } - /* good, add child to bus */ if ((dev = device_find_child(parent, driver->name, 0)) == NULL) dev = BUS_ADD_CHILD(parent, 0, driver->name, 0); - if (dev != NULL) - device_set_desc_copy(dev, id->desc); + if (dev != NULL) { + device_set_desc_copy(dev, id_p->desc); + + if (id_p->version == 2) { + /* set rcba */ + rcba = (pci_read_config(ich, ICH_RCBA, 4) & (0xffffc000)); + rc = bus_set_resource(ich, SYS_RES_MEMORY, 0, rcba, ICH_GCS_SIZE); + if (rc) + ichwd_verbose_printf(dev, "%s(): Can not set memory resource:0x%x\n", __func__, rcba); + else + ichwd_verbose_printf(dev, "%s(): This machine has TCO Version 2 wdt.\n", __func__); + } + } } static int @@ -257,12 +321,27 @@ static int ichwd_attach(device_t dev) { struct ichwd_softc *sc; + struct ichwd_device *id_p; + device_t ich; + unsigned int pmbase = 0; sc = device_get_softc(dev); sc->device = dev; + ich = ichwd_find_ich_lpc_bridge(&id_p); + if (ich == NULL) { + device_printf(sc->device, "Can not find ICH device.\n"); + goto fail; + } + sc->ich = ich; + sc->tco_version = id_p->version; + + /* get for ACPI base address */ + pmbase = pci_read_config(ich, ICH_PMBASE, 2) & ICH_PMBASE_MASK; if (pmbase == 0) { - printf("Not found\n"); + ichwd_verbose_printf(sc->device, "%s(): ICH PMBASE register is empty\n", + __func__); + goto fail; } /* allocate I/O register space */ @@ -287,6 +366,21 @@ ichwd_attach(device_t dev) } sc->tco_bst = rman_get_bustag(sc->tco_res); sc->tco_bsh = rman_get_bushandle(sc->tco_res); + + sc->gcs_rid = 0; + sc->gcs_res = bus_alloc_resource_any(ich, SYS_RES_MEMORY, &sc->gcs_rid, + RF_ACTIVE|RF_SHAREABLE); + if ( (sc->gcs_res == NULL) && (sc->tco_version != 1) ) { + device_printf(dev, "unable to reserve GCS registers\n"); + goto fail; + } + + if (ichwd_clear_noreboot(sc)) + goto fail; + + device_printf(dev, "%s (TCO version %d)\n", + device_get_desc(dev), sc->tco_version); + /* reset the watchdog status registers */ ichwd_sts_reset(sc); @@ -309,6 +403,10 @@ ichwd_attach(device_t dev) if (sc->smi_res != NULL) bus_release_resource(dev, SYS_RES_IOPORT, sc->smi_rid, sc->smi_res); + if (sc->gcs_res != NULL) + bus_release_resource(ich, SYS_RES_MEMORY, + sc->gcs_rid, sc->gcs_res); + return (ENXIO); } @@ -316,6 +414,7 @@ static int ichwd_detach(device_t dev) { struct ichwd_softc *sc; + device_t ich = NULL; sc = device_get_softc(dev); @@ -338,6 +437,10 @@ ichwd_detach(device_t dev) bus_release_resource(dev, SYS_RES_IOPORT, sc->tco_rid, sc->tco_res); bus_release_resource(dev, SYS_RES_IOPORT, sc->smi_rid, sc->smi_res); + /* deallocate memory resource */ + ich = ichwd_find_ich_lpc_bridge(NULL); + if ( (sc->gcs_res) && (ich) ) + bus_release_resource(ich, SYS_RES_MEMORY, sc->gcs_rid, sc->gcs_res); return (0); } diff -Nupr ichwd.orig/ichwd.h ichwd/ichwd.h --- ichwd.orig/ichwd.h Wed Apr 25 22:03:16 2007 +++ ichwd/ichwd.h Fri Apr 27 01:03:54 2007 @@ -35,11 +35,12 @@ struct ichwd_device { uint16_t vendor; uint16_t device; char *desc; + unsigned int version; }; struct ichwd_softc { device_t device; - + device_t ich; int active; unsigned int timeout; @@ -53,6 +54,11 @@ struct ichwd_softc { bus_space_tag_t tco_bst; bus_space_handle_t tco_bsh; + int gcs_rid; + struct resource *gcs_res; + + int tco_version; + eventhandler_tag ev_tag; }; @@ -70,6 +76,13 @@ struct ichwd_softc { #define DEVICEID_6300ESB 0x25a1 #define DEVICEID_82801FBR 0x2640 #define DEVICEID_ICH5 0x27b8 +#define DEVICEID_ICH6M 0x2641 +#define DEVICEID_ICH6W 0x2642 +#define DEVICEID_ICH7M 0x27b9 +#define DEVICEID_ICH7MDH 0x27bd +#define DEVICEID_ICH8 0x2810 +#define DEVICEID_ICH8DH 0x2812 +#define DEVICEID_ICH8DO 0x2814 /* ICH LPC Interface Bridge Registers */ #define ICH_GEN_STA 0xd4 @@ -111,6 +124,12 @@ struct ichwd_softc { /* control bits for TCO1_CNT */ #define TCO_TMR_HALT 0x0800 /* clear to enable WDT */ #define TCO_CNT_PRESERVE 0x0200 /* preserve these bits */ + +#define ICH_RCBA 0xf0 +#define ICH_GCS_OFFSET 0x3410 +#define ICH_GCS_SIZE 0x4 +#define GCS_NOREBOOT 0x00000020 +#define TCO_V2_TMR 0x12 /* TCO Timer Initial Value for V2 */ /* approximate length in nanoseconds of one WDT tick */ #define ICHWD_TICK 1800000000 From owner-freebsd-arch@FreeBSD.ORG Sat Apr 28 18:02:03 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 5C3AB16A401 for ; Sat, 28 Apr 2007 18:02:03 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp09.mail.ogk.yahoo.co.jp (ybbsmtp09.mail.ogk.yahoo.co.jp [124.83.153.129]) by mx1.freebsd.org (Postfix) with SMTP id CEDEB13C448 for ; Sat, 28 Apr 2007 18:02:02 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 98802 invoked by alias); 28 Apr 2007 18:02:01 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; b=WY3eWaOx4B6Va831uirljlyG62ItOKn2ktDRfsJspaysLMZL6H7mCMqvJUlpaDM53vwRlUOyI4kfyZK8+0Dk6WKkJAefhcyM+xI76l0t0jqviVtVW7E/cKRFDo/RQ3CL ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp09.mail.ogk.yahoo.co.jp with SMTP; 28 Apr 2007 18:02:01 -0000 X-Apparently-From: Message-ID: <46338C0F.9000608@ybb.ne.jp> Date: Sun, 29 Apr 2007 03:01:51 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-arch@freebsd.org References: <46337B06.9080102@ybb.ne.jp> In-Reply-To: <46337B06.9080102@ybb.ne.jp> Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2007 18:02:03 -0000 Hi, I found one of my fault after posting previous message, > + if (id_p->version == 2) { > + /* set rcba */ > + rcba = (pci_read_config(ich, ICH_RCBA, 4) & (0xffffc000)); > + rc = bus_set_resource(ich, SYS_RES_MEMORY, 0, rcba, ICH_GCS_SIZE); This line should have been rc = bus_set_resource(ich, SYS_RES_MEMORY, 0, rcba + ICH_GCS_OFFSET, ICH_GCS_SIZE); (note: ICH_GCS_OFFSET = 0x3410) Sorry. But I met another problem that watch dog count does not reach zero(As far as I see, it is reloaded automatically). I'll continue to debug the codes, if anyone has any kind of idea, please send me a comment. Regards, From owner-freebsd-arch@FreeBSD.ORG Sat Apr 28 18:32:22 2007 Return-Path: X-Original-To: freebsd-arch@freebsd.org Delivered-To: freebsd-arch@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 7727516A401 for ; Sat, 28 Apr 2007 18:32:22 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: from ybbsmtp11.mail.ogk.yahoo.co.jp (ybbsmtp11.mail.ogk.yahoo.co.jp [124.83.153.131]) by mx1.freebsd.org (Postfix) with SMTP id 0111913C46C for ; Sat, 28 Apr 2007 18:32:21 +0000 (UTC) (envelope-from takeharu1219@ybb.ne.jp) Received: (qmail 84842 invoked by alias); 28 Apr 2007 18:32:21 -0000 DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=ybb20050223; d=ybb.ne.jp; b=MlgxQI7dQR2i9tETV5QwXf6+WpyzZWoQhxtrYgxcPdbNAMOJXnmH4MxqWg8J0uH7/pLhl3nzGzTAOxFmbsG5GoOHHuma8QnEQpTDlwEeiPnzPPhbeGnJvj45cCTy8xno ; Received: from unknown (HELO ?127.0.0.1?) (takeharu1219@219.35.170.86 with plain) by ybbsmtp11.mail.ogk.yahoo.co.jp with SMTP; 28 Apr 2007 18:32:20 -0000 X-Apparently-From: Message-ID: <4633932A.8080602@ybb.ne.jp> Date: Sun, 29 Apr 2007 03:32:10 +0900 From: Takeharu KATO User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) MIME-Version: 1.0 To: freebsd-current@freebsd.org References: <46337B06.9080102@ybb.ne.jp> <46338C0F.9000608@ybb.ne.jp> In-Reply-To: <46338C0F.9000608@ybb.ne.jp> Content-Type: multipart/mixed; boundary="------------090403080905070803000903" Cc: freebsd-arch@freebsd.org Subject: Re: ichwd for ICH8 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 28 Apr 2007 18:32:22 -0000 This is a multi-part message in MIME format. --------------090403080905070803000903 Content-Type: text/plain; charset=ISO-2022-JP Content-Transfer-Encoding: 7bit Hi, I wrote ICH7 or later support patch for sys/dev/ichwd watch dog driver. I tested this patch on ICH8 compliant mother board(GIGA BYTE GA-965P-DS3). Please apply the patch. P.S. I'm sorry to send noisy mails on freebsd-arch ML. Takeharu KATO wrote: > Hi, > > I found one of my fault after posting previous message, > >> + if (id_p->version == 2) { >> + /* set rcba */ >> + rcba = (pci_read_config(ich, ICH_RCBA, 4) & (0xffffc000)); >> + rc = bus_set_resource(ich, SYS_RES_MEMORY, 0, rcba, ICH_GCS_SIZE); > This line should have been > rc = bus_set_resource(ich, SYS_RES_MEMORY, 0, > rcba + ICH_GCS_OFFSET, ICH_GCS_SIZE); > > (note: ICH_GCS_OFFSET = 0x3410) > > Sorry. > > But I met another problem that watch dog count does not reach zero(As > far as I see, it is reloaded automatically). > > I'll continue to debug the codes, if anyone has any kind of idea, > please send me a comment. > > Regards, > > > _______________________________________________ > freebsd-arch@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" > > --------------090403080905070803000903 Content-Type: text/plain; name="ichwd-ich8-support-20070428.patch" Content-Transfer-Encoding: base64 Content-Disposition: inline; filename="ichwd-ich8-support-20070428.patch" ZGlmZiAtTnVwciBpY2h3ZC5vcmlnL2ljaHdkLmMgaWNod2QvaWNod2QuYwotLS0gaWNod2Qu b3JpZy9pY2h3ZC5jCVdlZCBBcHIgMjUgMjI6MDM6MTYgMjAwNworKysgaWNod2QvaWNod2Qu YwlTdW4gQXByIDI5IDAzOjE2OjIzIDIwMDcKQEAgLTcxLDIwICs3MSwyNyBAQCBfX0ZCU0RJ RCgiJEZyZWVCU0Q6IHNyYy9zeXMvZGV2L2ljaHdkL2ljCiAjaW5jbHVkZSA8ZGV2L2ljaHdk L2ljaHdkLmg+CiAKIHN0YXRpYyBzdHJ1Y3QgaWNod2RfZGV2aWNlIGljaHdkX2RldmljZXNb XSA9IHsKLQl7IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF84MjgwMUFBLCAiSW50ZWwgODI4 MDFBQSB3YXRjaGRvZyB0aW1lciIgfSwKLQl7IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF84 MjgwMUFCLCAiSW50ZWwgODI4MDFBQiB3YXRjaGRvZyB0aW1lciIgfSwKLQl7IFZFTkRPUklE X0lOVEVMLCBERVZJQ0VJRF84MjgwMUJBLCAiSW50ZWwgODI4MDFCQSB3YXRjaGRvZyB0aW1l ciIgfSwKLQl7IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF84MjgwMUJBTSwgIkludGVsIDgy ODAxQkFNIHdhdGNoZG9nIHRpbWVyIiB9LAotCXsgVkVORE9SSURfSU5URUwsIERFVklDRUlE XzgyODAxQ0EsICJJbnRlbCA4MjgwMUNBIHdhdGNoZG9nIHRpbWVyIiB9LAotCXsgVkVORE9S SURfSU5URUwsIERFVklDRUlEXzgyODAxQ0FNLCAiSW50ZWwgODI4MDFDQU0gd2F0Y2hkb2cg dGltZXIiIH0sCi0JeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNFSURfODI4MDFEQiwgIkludGVs IDgyODAxREIgd2F0Y2hkb2cgdGltZXIiIH0sCi0JeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNF SURfODI4MDFEQk0sICJJbnRlbCA4MjgwMURCTSB3YXRjaGRvZyB0aW1lciIgfSwKLQl7IFZF TkRPUklEX0lOVEVMLCBERVZJQ0VJRF84MjgwMUUsICJJbnRlbCA4MjgwMUUgd2F0Y2hkb2cg dGltZXIiIH0sCi0JeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNFSURfODI4MDFFQlIsICJJbnRl bCA4MjgwMUVCL0VSIHdhdGNoZG9nIHRpbWVyIiB9LAotCXsgVkVORE9SSURfSU5URUwsIERF VklDRUlEXzgyODAxRkJSLCAiSW50ZWwgODI4MDFGQi9GUiB3YXRjaGRvZyB0aW1lciIgfSwK LQl7IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF9JQ0g1LCAiSW50ZWwgSUNINSB3YXRjaGRv ZyB0aW1lciJ9LAotCXsgVkVORE9SSURfSU5URUwsIERFVklDRUlEXzYzMDBFU0IsICJJbnRl bCA2MzAwRVNCIHdhdGNoZG9nIHRpbWVyIn0sCi0JeyAwLCAwLCBOVUxMIH0sCisJeyBWRU5E T1JJRF9JTlRFTCwgREVWSUNFSURfODI4MDFBQSwgICJJbnRlbCA4MjgwMUFBIHdhdGNoZG9n IHRpbWVyIiwgICAgMX0gLAorCXsgVkVORE9SSURfSU5URUwsIERFVklDRUlEXzgyODAxQUIs ICAiSW50ZWwgODI4MDFBQiB3YXRjaGRvZyB0aW1lciIsICAgIDF9ICwKKwl7IFZFTkRPUklE X0lOVEVMLCBERVZJQ0VJRF84MjgwMUJBLCAgIkludGVsIDgyODAxQkEgd2F0Y2hkb2cgdGlt ZXIiLCAgICAxfSAsCisJeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNFSURfODI4MDFCQU0sICJJ bnRlbCA4MjgwMUJBTSB3YXRjaGRvZyB0aW1lciIsICAgMX0gLAorCXsgVkVORE9SSURfSU5U RUwsIERFVklDRUlEXzgyODAxQ0EsICAiSW50ZWwgODI4MDFDQSB3YXRjaGRvZyB0aW1lciIs ICAgIDF9ICwKKwl7IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF84MjgwMUNBTSwgIkludGVs IDgyODAxQ0FNIHdhdGNoZG9nIHRpbWVyIiwgICAxfSAsCisJeyBWRU5ET1JJRF9JTlRFTCwg REVWSUNFSURfODI4MDFEQiwgICJJbnRlbCA4MjgwMURCIHdhdGNoZG9nIHRpbWVyIiwgICAg MX0gLAorCXsgVkVORE9SSURfSU5URUwsIERFVklDRUlEXzgyODAxREJNLCAiSW50ZWwgODI4 MDFEQk0gd2F0Y2hkb2cgdGltZXIiLCAgIDF9ICwKKwl7IFZFTkRPUklEX0lOVEVMLCBERVZJ Q0VJRF84MjgwMUUsICAgIkludGVsIDgyODAxRSB3YXRjaGRvZyB0aW1lciIsICAgICAxfSAs CisJeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNFSURfODI4MDFFQlIsICJJbnRlbCA4MjgwMUVC L0VSIHdhdGNoZG9nIHRpbWVyIiwgMX0gLAorCXsgVkVORE9SSURfSU5URUwsIERFVklDRUlE XzgyODAxRkJSLCAiSW50ZWwgODI4MDFGQi9GUiB3YXRjaGRvZyB0aW1lciIsIDJ9ICwKKwl7 IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF82MzAwRVNCLCAgIkludGVsIDYzMDBFU0Igd2F0 Y2hkb2cgdGltZXIiLCAgICAyfSAsCisJeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNFSURfSUNI Nk0sICAgICJJbnRlbCBJQ0g2TSB3YXRjaGRvZyB0aW1lciIsICAgICAgMn0gLAorCXsgVkVO RE9SSURfSU5URUwsIERFVklDRUlEX0lDSDZXLCAgICAiSW50ZWwgSUNINlcgd2F0Y2hkb2cg dGltZXIiLCAgICAgIDJ9ICwKKwl7IFZFTkRPUklEX0lOVEVMLCBERVZJQ0VJRF9JQ0g3LCAg ICAgIkludGVsIElDSDcgd2F0Y2hkb2cgdGltZXIiLCAgICAgICAyfSAsCisJeyBWRU5ET1JJ RF9JTlRFTCwgREVWSUNFSURfSUNIN00sICAgICJJbnRlbCBJQ0g3TSB3YXRjaGRvZyB0aW1l ciIsICAgICAgMn0gLAorCXsgVkVORE9SSURfSU5URUwsIERFVklDRUlEX0lDSDdNREgsICAi SW50ZWwgSUNIN01ESCB3YXRjaGRvZyB0aW1lciIsICAgIDJ9ICwKKwl7IFZFTkRPUklEX0lO VEVMLCBERVZJQ0VJRF9JQ0g4LCAgICAgIkludGVsIElDSDggd2F0Y2hkb2cgdGltZXIiLCAg ICAgICAyfSAsCisJeyBWRU5ET1JJRF9JTlRFTCwgREVWSUNFSURfSUNIOERILCAgICJJbnRl bCBJQ0g4REggd2F0Y2hkb2cgdGltZXIiLCAgICAgMn0gLAorCXsgVkVORE9SSURfSU5URUws IERFVklDRUlEX0lDSDhETywgICAiSW50ZWwgSUNIOERPIHdhdGNoZG9nIHRpbWVyIiwgICAg IDJ9ICwKKwl7IDAsIDAsIE5VTEwsIDAgfSAsCiB9OwogCiBzdGF0aWMgZGV2Y2xhc3NfdCBp Y2h3ZF9kZXZjbGFzczsKQEAgLTEwMywxMSArMTEwLDIxIEBAIHN0YXRpYyBkZXZjbGFzc190 IGljaHdkX2RldmNsYXNzOwogI2RlZmluZSBpY2h3ZF93cml0ZV90Y29fNChzYywgb2ZmLCB2 YWwpIFwKIAlidXNfc3BhY2Vfd3JpdGVfNCgoc2MpLT50Y29fYnN0LCAoc2MpLT50Y29fYnNo LCAob2ZmKSwgKHZhbCkpCiAKLSNkZWZpbmUgaWNod2RfcmVhZF9zbWlfNChzYywgb2ZmKSBc CisjZGVmaW5lIGljaHdkX3JlYWRfc21pXzQoc2MsIG9mZikgICAgICAgXAogCWJ1c19zcGFj ZV9yZWFkXzQoKHNjKS0+c21pX2JzdCwgKHNjKS0+c21pX2JzaCwgKG9mZikpCiAjZGVmaW5l IGljaHdkX3dyaXRlX3NtaV80KHNjLCBvZmYsIHZhbCkgXAogCWJ1c19zcGFjZV93cml0ZV80 KChzYyktPnNtaV9ic3QsIChzYyktPnNtaV9ic2gsIChvZmYpLCAodmFsKSkKIAorI2RlZmlu ZSBpY2h3ZF9yZWFkX2djc180KHNjLCBvZmYpICAgICAgIFwKKwlidXNfcmVhZF80KChzYykt Pmdjc19yZXMsIChvZmYpKQorI2RlZmluZSBpY2h3ZF93cml0ZV9nY3NfNChzYywgb2ZmLCB2 YWwpIFwKKwlidXNfd3JpdGVfNCgoc2MpLT5nY3NfcmVzLCAob2ZmKSwgKHZhbCkpCisKKyNk ZWZpbmUgaWNod2RfdmVyYm9zZV9wcmludGYoZGV2LGZtdCxhcmcuLi4pIGRvIHsJXAorCQlp ZiAoYm9vdHZlcmJvc2UpCQkJXAorCQkJZGV2aWNlX3ByaW50ZihkZXYsIGZtdCwgIyNhcmcp OwlcCisJfSB3aGlsZSAoMCkKKwogc3RhdGljIF9faW5saW5lIHZvaWQKIGljaHdkX2ludHJf ZW5hYmxlKHN0cnVjdCBpY2h3ZF9zb2Z0YyAqc2MpCiB7CkBAIC0xMzYsOCArMTUzLDcgQEAg aWNod2RfdG1yX2VuYWJsZShzdHJ1Y3QgaWNod2Rfc29mdGMgKnNjKQogCWNudCA9IGljaHdk X3JlYWRfdGNvXzIoc2MsIFRDTzFfQ05UKSAmIFRDT19DTlRfUFJFU0VSVkU7CiAJaWNod2Rf d3JpdGVfdGNvXzIoc2MsIFRDTzFfQ05ULCBjbnQgJiB+VENPX1RNUl9IQUxUKTsKIAlzYy0+ YWN0aXZlID0gMTsKLQlpZiAoYm9vdHZlcmJvc2UpCi0JCWRldmljZV9wcmludGYoc2MtPmRl dmljZSwgInRpbWVyIGVuYWJsZWRcbiIpOworCWljaHdkX3ZlcmJvc2VfcHJpbnRmKHNjLT5k ZXZpY2UsICJ0aW1lciBlbmFibGVkXG4iKTsKIH0KIAogc3RhdGljIF9faW5saW5lIHZvaWQK QEAgLTE0OCwyNSArMTY0LDY3IEBAIGljaHdkX3Rtcl9kaXNhYmxlKHN0cnVjdCBpY2h3ZF9z b2Z0YyAqc2MKIAljbnQgPSBpY2h3ZF9yZWFkX3Rjb18yKHNjLCBUQ08xX0NOVCkgJiBUQ09f Q05UX1BSRVNFUlZFOwogCWljaHdkX3dyaXRlX3Rjb18yKHNjLCBUQ08xX0NOVCwgY250IHwg VENPX1RNUl9IQUxUKTsKIAlzYy0+YWN0aXZlID0gMDsKLQlpZiAoYm9vdHZlcmJvc2UpCi0J CWRldmljZV9wcmludGYoc2MtPmRldmljZSwgInRpbWVyIGRpc2FibGVkXG4iKTsKKwlpY2h3 ZF92ZXJib3NlX3ByaW50ZihzYy0+ZGV2aWNlLCAidGltZXIgZGlzYWJsZWRcbiIpOwogfQog CiBzdGF0aWMgX19pbmxpbmUgdm9pZAogaWNod2RfdG1yX3JlbG9hZChzdHJ1Y3QgaWNod2Rf c29mdGMgKnNjKQogewotCWljaHdkX3dyaXRlX3Rjb18xKHNjLCBUQ09fUkxELCAxKTsKLQlp ZiAoYm9vdHZlcmJvc2UpCi0JCWRldmljZV9wcmludGYoc2MtPmRldmljZSwgInRpbWVyIHJl bG9hZGVkXG4iKTsKKwlpZiAoc2MtPnRjb192ZXJzaW9uID09IDEpCisJCWljaHdkX3dyaXRl X3Rjb18xKHNjLCBUQ09fUkxELCAxKTsKKwllbHNlCisJCWljaHdkX3dyaXRlX3Rjb18yKHNj LCBUQ09fUkxELCAxKTsKKworCWljaHdkX3ZlcmJvc2VfcHJpbnRmKHNjLT5kZXZpY2UsICJ0 aW1lciByZWxvYWRlZFxuIik7CiB9CiAKIHN0YXRpYyBfX2lubGluZSB2b2lkCiBpY2h3ZF90 bXJfc2V0KHN0cnVjdCBpY2h3ZF9zb2Z0YyAqc2MsIHVpbnQ4X3QgdGltZW91dCkKIHsKLQlp Y2h3ZF93cml0ZV90Y29fMShzYywgVENPX1RNUiwgdGltZW91dCk7CisKKwlpZiAoc2MtPnRj b192ZXJzaW9uID09IDEpIHsKKwkJaWNod2Rfd3JpdGVfdGNvXzEoc2MsIFRDT19UTVIsIHRp bWVvdXQpOworCX0gZWxzZSB7CisJCXVpbnQxNl90IHRtcl92YWwgPSBpY2h3ZF9yZWFkX3Rj b18yKHNjLCBUQ09fVjJfVE1SKTsKKworCQl0bXJfdmFsICY9IDB4ZmMwMDsKKwkJdG1yX3Zh bCB8PSB0aW1lb3V0OworCQlpY2h3ZF93cml0ZV90Y29fMihzYywgVENPX1YyX1RNUiwgdG1y X3ZhbCk7CisJfQorCiAJc2MtPnRpbWVvdXQgPSB0aW1lb3V0OwotCWlmIChib290dmVyYm9z ZSkKLQkJZGV2aWNlX3ByaW50ZihzYy0+ZGV2aWNlLCAidGltZW91dCBzZXQgdG8gJXUgdGlj a3NcbiIsIHRpbWVvdXQpOworCisJaWNod2RfdmVyYm9zZV9wcmludGYoc2MtPmRldmljZSwg InRpbWVvdXQgc2V0IHRvICV1IHRpY2tzXG4iLCB0aW1lb3V0KTsKK30KKworc3RhdGljIF9f aW5saW5lIGludAoraWNod2RfY2xlYXJfbm9yZWJvb3Qoc3RydWN0IGljaHdkX3NvZnRjICpz YykKK3sKKwl1aW50MzJfdAlzdGF0dXM7CisJaW50CQlyYyA9IDA7CisKKwkvKiB0cnkgdG8g Y2xlYXIgdGhlIE5PX1JFQk9PVCBiaXQgKi8KKwlpZiAoc2MtPnRjb192ZXJzaW9uID09IDEp IHsKKwkJcGNpX3dyaXRlX2NvbmZpZyhzYy0+aWNoLCBJQ0hfR0VOX1NUQSwgMHgwMCwgMSk7 CisJCXN0YXR1cyA9IHBjaV9yZWFkX2NvbmZpZyhzYy0+aWNoLCBJQ0hfR0VOX1NUQSwgMSk7 CisJCWlmIChzdGF0dXMgJiBJQ0hfR0VOX1NUQV9OT19SRUJPT1QpIAorCQkJcmMgPSBFSU87 CisJfSBlbHNlIHsKKwkgICAgIHN0YXR1cyA9IGljaHdkX3JlYWRfZ2NzXzQoc2MsIDApOwor CSAgICAgc3RhdHVzICY9IH4oR0NTX05PUkVCT09UKTsKKwkgICAgIGljaHdkX3dyaXRlX2dj c180KHNjLCAwLCBzdGF0dXMpOworCisJICAgICBzdGF0dXMgPSBpY2h3ZF9yZWFkX2djc180 KHNjLCAwKTsKKwkgICAgIGlmIChzdGF0dXMgJiBHQ1NfTk9SRUJPT1QpIAorCQkgICAgIHJj ID0gRUlPOworCX0KKworCWlmIChyYykKKwkJaWNod2RfdmVyYm9zZV9wcmludGYoc2MtPmRl dmljZSwgCisJCQkJICAgICAiJXMoKTogSUNIIFdEVCBwcmVzZW50IGJ1dCBkaXNhYmxlZFxu IiwKKwkJCQkgICAgIF9fZnVuY19fKTsKKworCXJldHVybiByYzsKIH0KIAogLyoKQEAgLTE5 Nyw3ICsyNTUsMjQgQEAgaWNod2RfZXZlbnQodm9pZCAqYXJnLCB1bnNpZ25lZCBpbnQgY21k LAogCX0KIH0KIAotc3RhdGljIHVuc2lnbmVkIGludCBwbWJhc2UgPSAwOworc3RhdGljIGRl dmljZV90IAoraWNod2RfZmluZF9pY2hfbHBjX2JyaWRnZShzdHJ1Y3QgaWNod2RfZGV2aWNl ICoqaWRfcCkgeworCXN0cnVjdCBpY2h3ZF9kZXZpY2UgKmlkOworCWRldmljZV90IGljaCA9 IE5VTEw7CisKKyAgICAgICAgLyogbG9vayBmb3IgYW4gSUNIIExQQyBpbnRlcmZhY2UgYnJp ZGdlICovCisJZm9yIChpZCA9IGljaHdkX2RldmljZXM7IGlkLT5kZXNjICE9IE5VTEw7ICsr aWQpCisJCWlmICgoaWNoID0gcGNpX2ZpbmRfZGV2aWNlKGlkLT52ZW5kb3IsIGlkLT5kZXZp Y2UpKSAhPSBOVUxMKQorCQkJYnJlYWs7CisKKwlpZiAoIChib290dmVyYm9zZSkgJiYgKGlj aCkgKQorCQlwcmludGYoIiVzKCk6IGZvdW5kIElDSCBjaGlwc2V0OiAlcyBUQ08gdmVyc2lv bjolZFxuIiwgX19mdW5jX18sIGlkLT5kZXNjLCBpZC0+dmVyc2lvbik7CisKKwlpZiAoaWRf cCkKKwkJKmlkX3AgPSBpZDsKKworCXJldHVybiBpY2g7Cit9CiAKIC8qCiAgKiBMb29rIGZv ciBhbiBJQ0ggTFBDIGludGVyZmFjZSBicmlkZ2UuICBJZiBvbmUgaXMgZm91bmQsIHJlZ2lz dGVyIGFuCkBAIC0yMDYsNDQgKzI4MSwzNSBAQCBzdGF0aWMgdW5zaWduZWQgaW50IHBtYmFz ZSA9IDA7CiBzdGF0aWMgdm9pZAogaWNod2RfaWRlbnRpZnkoZHJpdmVyX3QgKmRyaXZlciwg ZGV2aWNlX3QgcGFyZW50KQogewotCXN0cnVjdCBpY2h3ZF9kZXZpY2UgKmlkOworCXN0cnVj dCBpY2h3ZF9kZXZpY2UgKmlkX3A7CiAJZGV2aWNlX3QgaWNoID0gTlVMTDsKIAlkZXZpY2Vf dCBkZXY7CisJdWludDMyX3QgcmNiYTsKKwlpbnQgcmM7CiAKLQkvKiBsb29rIGZvciBhbiBJ Q0ggTFBDIGludGVyZmFjZSBicmlkZ2UgKi8KLQlmb3IgKGlkID0gaWNod2RfZGV2aWNlczsg aWQtPmRlc2MgIT0gTlVMTDsgKytpZCkKLQkJaWYgKChpY2ggPSBwY2lfZmluZF9kZXZpY2Uo aWQtPnZlbmRvciwgaWQtPmRldmljZSkpICE9IE5VTEwpCi0JCQlicmVhazsKKwlpY2ggPSBp Y2h3ZF9maW5kX2ljaF9scGNfYnJpZGdlKCZpZF9wKTsKIAlpZiAoaWNoID09IE5VTEwpCiAJ CXJldHVybjsKIAotCWlmIChib290dmVyYm9zZSkKLQkJcHJpbnRmKCIlcygpOiBmb3VuZCBJ Q0ggY2hpcHNldDogJXNcbiIsIF9fZnVuY19fLCBpZC0+ZGVzYyk7Ci0KLQkvKiBnZXQgZm9y IEFDUEkgYmFzZSBhZGRyZXNzICovCi0JcG1iYXNlID0gcGNpX3JlYWRfY29uZmlnKGljaCwg SUNIX1BNQkFTRSwgMikgJiBJQ0hfUE1CQVNFX01BU0s7Ci0JaWYgKHBtYmFzZSA9PSAwKSB7 Ci0JCWlmIChib290dmVyYm9zZSkKLQkJCXByaW50ZigiJXMoKTogSUNIIFBNQkFTRSByZWdp c3RlciBpcyBlbXB0eVxuIiwKLQkJCSAgICBfX2Z1bmNfXyk7Ci0JCXJldHVybjsKLQl9Ci0K LQkvKiB0cnkgdG8gY2xlYXIgdGhlIE5PX1JFQk9PVCBiaXQgKi8KLQlwY2lfd3JpdGVfY29u ZmlnKGljaCwgSUNIX0dFTl9TVEEsIDB4MDAsIDEpOwotCWlmIChwY2lfcmVhZF9jb25maWco aWNoLCBJQ0hfR0VOX1NUQSwgMSkgJiBJQ0hfR0VOX1NUQV9OT19SRUJPT1QpIHsKLQkJaWYg KGJvb3R2ZXJib3NlKQotCQkJcHJpbnRmKCIlcygpOiBJQ0ggV0RUIHByZXNlbnQgYnV0IGRp c2FibGVkXG4iLAotCQkJICAgIF9fZnVuY19fKTsKLQkJcmV0dXJuOwotCX0KLQogCS8qIGdv b2QsIGFkZCBjaGlsZCB0byBidXMgKi8KIAlpZiAoKGRldiA9IGRldmljZV9maW5kX2NoaWxk KHBhcmVudCwgZHJpdmVyLT5uYW1lLCAwKSkgPT0gTlVMTCkKIAkJZGV2ID0gQlVTX0FERF9D SElMRChwYXJlbnQsIDAsIGRyaXZlci0+bmFtZSwgMCk7CiAKLQlpZiAoZGV2ICE9IE5VTEwp Ci0JCWRldmljZV9zZXRfZGVzY19jb3B5KGRldiwgaWQtPmRlc2MpOworCWlmIChkZXYgIT0g TlVMTCkgeworCQlkZXZpY2Vfc2V0X2Rlc2NfY29weShkZXYsIGlkX3AtPmRlc2MpOworCisJ CWlmIChpZF9wLT52ZXJzaW9uID09IDIpIHsKKwkJCS8qIHNldCByY2JhICovCisJCQlyY2Jh ID0gKHBjaV9yZWFkX2NvbmZpZyhpY2gsIElDSF9SQ0JBLCA0KSAmICgweGZmZmZjMDAwKSk7 CisJCQlyYyA9IGJ1c19zZXRfcmVzb3VyY2UoaWNoLCBTWVNfUkVTX01FTU9SWSwgMCwgCisJ CQkJCSAgICAgIHJjYmEgKyBJQ0hfR0NTX09GRlNFVCwgCisJCQkJCSAgICAgIElDSF9HQ1Nf U0laRSk7CisJCQlpZiAocmMpCisJCQkJaWNod2RfdmVyYm9zZV9wcmludGYoZGV2LCAiJXMo KTogQ2FuIG5vdCBzZXQgbWVtb3J5IHJlc291cmNlOjB4JXhcbiIsIF9fZnVuY19fLCByY2Jh KTsKKwkJCWVsc2UKKwkJCQlpY2h3ZF92ZXJib3NlX3ByaW50ZihkZXYsICIlcygpOiBUaGlz IG1hY2hpbmUgaGFzIFRDTyBWZXJzaW9uIDIgd2R0LlxuIiwgX19mdW5jX18pOworCQl9CisJ fQogfQogCiBzdGF0aWMgaW50CkBAIC0yNTcsMTIgKzMyMywyNyBAQCBzdGF0aWMgaW50CiBp Y2h3ZF9hdHRhY2goZGV2aWNlX3QgZGV2KQogewogCXN0cnVjdCBpY2h3ZF9zb2Z0YyAqc2M7 CisJc3RydWN0IGljaHdkX2RldmljZSAqaWRfcDsKKwlkZXZpY2VfdCBpY2g7CisJdW5zaWdu ZWQgaW50IHBtYmFzZSA9IDA7CiAKIAlzYyA9IGRldmljZV9nZXRfc29mdGMoZGV2KTsKIAlz Yy0+ZGV2aWNlID0gZGV2OwogCisJaWNoID0gaWNod2RfZmluZF9pY2hfbHBjX2JyaWRnZSgm aWRfcCk7CisJaWYgKGljaCA9PSBOVUxMKSB7CisJCWRldmljZV9wcmludGYoc2MtPmRldmlj ZSwgIkNhbiBub3QgZmluZCBJQ0ggZGV2aWNlLlxuIik7CisJCWdvdG8gZmFpbDsKKwl9CisJ c2MtPmljaCA9IGljaDsKKwlzYy0+dGNvX3ZlcnNpb24gPSBpZF9wLT52ZXJzaW9uOworCisJ LyogZ2V0IGZvciBBQ1BJIGJhc2UgYWRkcmVzcyAqLworCXBtYmFzZSA9IHBjaV9yZWFkX2Nv bmZpZyhpY2gsIElDSF9QTUJBU0UsIDIpICYgSUNIX1BNQkFTRV9NQVNLOwogCWlmIChwbWJh c2UgPT0gMCkgewotCQlwcmludGYoIk5vdCBmb3VuZFxuIik7CisJCWljaHdkX3ZlcmJvc2Vf cHJpbnRmKHNjLT5kZXZpY2UsICIlcygpOiBJQ0ggUE1CQVNFIHJlZ2lzdGVyIGlzIGVtcHR5 XG4iLAorCQkJICAgIF9fZnVuY19fKTsKKwkJZ290byBmYWlsOwogCX0KIAogCS8qIGFsbG9j YXRlIEkvTyByZWdpc3RlciBzcGFjZSAqLwpAQCAtMjg3LDYgKzM2OCwyMSBAQCBpY2h3ZF9h dHRhY2goZGV2aWNlX3QgZGV2KQogCX0KIAlzYy0+dGNvX2JzdCA9IHJtYW5fZ2V0X2J1c3Rh ZyhzYy0+dGNvX3Jlcyk7CiAJc2MtPnRjb19ic2ggPSBybWFuX2dldF9idXNoYW5kbGUoc2Mt PnRjb19yZXMpOworCisJc2MtPmdjc19yaWQgPSAwOworCXNjLT5nY3NfcmVzID0gYnVzX2Fs bG9jX3Jlc291cmNlX2FueShpY2gsIFNZU19SRVNfTUVNT1JZLCAmc2MtPmdjc19yaWQsCisJ CQkJCSAgICAgUkZfQUNUSVZFfFJGX1NIQVJFQUJMRSk7CisJaWYgKCAoc2MtPmdjc19yZXMg PT0gTlVMTCkgJiYgKHNjLT50Y29fdmVyc2lvbiAhPSAxKSApIHsKKwkJZGV2aWNlX3ByaW50 ZihkZXYsICJ1bmFibGUgdG8gcmVzZXJ2ZSBHQ1MgcmVnaXN0ZXJzXG4iKTsKKwkJZ290byBm YWlsOworCX0KKworCWlmIChpY2h3ZF9jbGVhcl9ub3JlYm9vdChzYykpCisJCWdvdG8gZmFp bDsKKworCWRldmljZV9wcmludGYoZGV2LCAiJXMgKFRDTyB2ZXJzaW9uICVkKVxuIiwKKwkJ ICAgICAgZGV2aWNlX2dldF9kZXNjKGRldiksIHNjLT50Y29fdmVyc2lvbik7CisKIAkvKiBy ZXNldCB0aGUgd2F0Y2hkb2cgc3RhdHVzIHJlZ2lzdGVycyAqLwogCiAJaWNod2Rfc3RzX3Jl c2V0KHNjKTsKQEAgLTMwOSw2ICs0MDUsMTAgQEAgaWNod2RfYXR0YWNoKGRldmljZV90IGRl dikKIAlpZiAoc2MtPnNtaV9yZXMgIT0gTlVMTCkKIAkJYnVzX3JlbGVhc2VfcmVzb3VyY2Uo ZGV2LCBTWVNfUkVTX0lPUE9SVCwKIAkJICAgIHNjLT5zbWlfcmlkLCBzYy0+c21pX3Jlcyk7 CisJaWYgKHNjLT5nY3NfcmVzICE9IE5VTEwpCisJCWJ1c19yZWxlYXNlX3Jlc291cmNlKGlj aCwgU1lTX1JFU19NRU1PUlksCisJCSAgICBzYy0+Z2NzX3JpZCwgc2MtPmdjc19yZXMpOwor CiAJcmV0dXJuIChFTlhJTyk7CiB9CiAKQEAgLTMxNiw2ICs0MTYsNyBAQCBzdGF0aWMgaW50 CiBpY2h3ZF9kZXRhY2goZGV2aWNlX3QgZGV2KQogewogCXN0cnVjdCBpY2h3ZF9zb2Z0YyAq c2M7CisJZGV2aWNlX3QgaWNoID0gTlVMTDsKIAogCXNjID0gZGV2aWNlX2dldF9zb2Z0Yyhk ZXYpOwogCkBAIC0zMzgsNiArNDM5LDEwIEBAIGljaHdkX2RldGFjaChkZXZpY2VfdCBkZXYp CiAJYnVzX3JlbGVhc2VfcmVzb3VyY2UoZGV2LCBTWVNfUkVTX0lPUE9SVCwgc2MtPnRjb19y aWQsIHNjLT50Y29fcmVzKTsKIAlidXNfcmVsZWFzZV9yZXNvdXJjZShkZXYsIFNZU19SRVNf SU9QT1JULCBzYy0+c21pX3JpZCwgc2MtPnNtaV9yZXMpOwogCisJLyogZGVhbGxvY2F0ZSBt ZW1vcnkgcmVzb3VyY2UgKi8KKwlpY2ggPSBpY2h3ZF9maW5kX2ljaF9scGNfYnJpZGdlKE5V TEwpOworCWlmICggKHNjLT5nY3NfcmVzKSAmJiAoaWNoKSApIAorCQlidXNfcmVsZWFzZV9y ZXNvdXJjZShpY2gsIFNZU19SRVNfTUVNT1JZLCBzYy0+Z2NzX3JpZCwgc2MtPmdjc19yZXMp OwogCXJldHVybiAoMCk7CiB9CiAKZGlmZiAtTnVwciBpY2h3ZC5vcmlnL2ljaHdkLmggaWNo d2QvaWNod2QuaAotLS0gaWNod2Qub3JpZy9pY2h3ZC5oCVdlZCBBcHIgMjUgMjI6MDM6MTYg MjAwNworKysgaWNod2QvaWNod2QuaAlTdW4gQXByIDI5IDAzOjE0OjQ5IDIwMDcKQEAgLTM1 LDExICszNSwxMiBAQCBzdHJ1Y3QgaWNod2RfZGV2aWNlIHsKIAl1aW50MTZfdAkJIHZlbmRv cjsKIAl1aW50MTZfdAkJIGRldmljZTsKIAljaGFyCQkJKmRlc2M7CisJdW5zaWduZWQgaW50 CXZlcnNpb247CiB9OwogCiBzdHJ1Y3QgaWNod2Rfc29mdGMgewogCWRldmljZV90CQkgZGV2 aWNlOwotCisJZGV2aWNlX3QgCQkgaWNoOwogCWludAkJCSBhY3RpdmU7CiAJdW5zaWduZWQg aW50CQkgdGltZW91dDsKIApAQCAtNTMsNiArNTQsMTEgQEAgc3RydWN0IGljaHdkX3NvZnRj IHsKIAlidXNfc3BhY2VfdGFnX3QJCSB0Y29fYnN0OwogCWJ1c19zcGFjZV9oYW5kbGVfdAkg dGNvX2JzaDsKIAorCWludAkJCSBnY3NfcmlkOworCXN0cnVjdCByZXNvdXJjZQkJKmdjc19y ZXM7CisKKwlpbnQgICAgICAgICAgICAgICAgICAgICAgdGNvX3ZlcnNpb247CisKIAlldmVu dGhhbmRsZXJfdGFnCSBldl90YWc7CiB9OwogCkBAIC02OSw3ICs3NSwxNCBAQCBzdHJ1Y3Qg aWNod2Rfc29mdGMgewogI2RlZmluZSBERVZJQ0VJRF84MjgwMUVCUgkweDI0ZDAKICNkZWZp bmUgREVWSUNFSURfNjMwMEVTQgkweDI1YTEKICNkZWZpbmUgREVWSUNFSURfODI4MDFGQlIJ MHgyNjQwCi0jZGVmaW5lIERFVklDRUlEX0lDSDUJCTB4MjdiOAorI2RlZmluZSBERVZJQ0VJ RF9JQ0g2TQkJMHgyNjQxCisjZGVmaW5lIERFVklDRUlEX0lDSDZXCQkweDI2NDIKKyNkZWZp bmUgREVWSUNFSURfSUNINwkJMHgyN2I4CisjZGVmaW5lIERFVklDRUlEX0lDSDdNCQkweDI3 YjkKKyNkZWZpbmUgREVWSUNFSURfSUNIN01ESAkweDI3YmQKKyNkZWZpbmUgREVWSUNFSURf SUNIOAkJMHgyODEwCisjZGVmaW5lIERFVklDRUlEX0lDSDhESAkJMHgyODEyCisjZGVmaW5l IERFVklDRUlEX0lDSDhETwkJMHgyODE0CiAKIC8qIElDSCBMUEMgSW50ZXJmYWNlIEJyaWRn ZSBSZWdpc3RlcnMgKi8KICNkZWZpbmUgSUNIX0dFTl9TVEEJCTB4ZDQKQEAgLTExMSw2ICsx MjQsMTIgQEAgc3RydWN0IGljaHdkX3NvZnRjIHsKIC8qIGNvbnRyb2wgYml0cyBmb3IgVENP MV9DTlQgKi8KICNkZWZpbmUgVENPX1RNUl9IQUxUCQkweDA4MDAgLyogY2xlYXIgdG8gZW5h YmxlIFdEVCAqLwogI2RlZmluZSBUQ09fQ05UX1BSRVNFUlZFCTB4MDIwMCAvKiBwcmVzZXJ2 ZSB0aGVzZSBiaXRzICovCisKKyNkZWZpbmUgSUNIX1JDQkEJCTB4ZjAgIAorI2RlZmluZSBJ Q0hfR0NTX09GRlNFVAkJMHgzNDEwCisjZGVmaW5lIElDSF9HQ1NfU0laRQkJMHg0CisjZGVm aW5lIEdDU19OT1JFQk9PVAkJMHgwMDAwMDAyMAorI2RlZmluZSBUQ09fVjJfVE1SCQkweDEy IC8qIFRDTyBUaW1lciBJbml0aWFsIFZhbHVlIGZvciBWMiAqLwogCiAvKiBhcHByb3hpbWF0 ZSBsZW5ndGggaW4gbmFub3NlY29uZHMgb2Ygb25lIFdEVCB0aWNrICovCiAjZGVmaW5lIElD SFdEX1RJQ0sJCTE4MDAwMDAwMDAK --------------090403080905070803000903--