From owner-freebsd-acpi@FreeBSD.ORG Sat Jul 19 14:11:06 2014 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C4FE0976 for ; Sat, 19 Jul 2014 14:11:06 +0000 (UTC) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 3E7EF2EF3 for ; Sat, 19 Jul 2014 14:11:05 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id s6JEAp4r077469; Sun, 20 Jul 2014 00:10:51 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sun, 20 Jul 2014 00:10:51 +1000 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: atrtc.c patch for ACPI CMOS region (was Re: ACPI support - Freebsd 10 on Sony Vaio VPCCA3C5E) In-Reply-To: <53C6E9B3.1080402@att.net> Message-ID: <20140718212933.N8638@sola.nimnet.asn.au> References: <53C020CE.8010205@att.net> <53C02604.9070207@att.net> <53C3D322.3080302@att.net> <20140716040719.Y50382@sola.nimnet.asn.au> <20140716143406.V50382@sola.nimnet.asn.au> <53C67D70.6060603@att.net> <20140717011710.W50382@sola.nimnet.asn.au> <53C6E9B3.1080402@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org, Daniele Mazzotti X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 19 Jul 2014 14:11:06 -0000 On Wed, 16 Jul 2014 17:08:03 -0400, Anthony Jenkins wrote: > On 07/16/2014 13:16, Ian Smith wrote: [..] > > > http://pastebin.com/P0B44u0c > > > > Either by show raw and save, or by download, the patch has ^M lineends. > Bah! Well that'd explain it... I'm generating the file on a pure > FreeBSD box, opened in gvim, select all, copy, paste to pastebin.com. Must be pastebin .. a sh script I grabbed from there came like that too. > > Interesting, but I can't see atrtc.c being the right sort of place for > > this, seems way out of scope. Couldn't you include its headers and use > > functions rtcin() and writertc() from elsewhere in kernel, perhaps a > > module living in the same hierarchy as acpi_ibm, acpi_asus and such, > > that one could build and kldload if useful on a certain machine/s? > This is in support of the PNP0800 device, for which atrtc.c is the > driver. The ACPI spec (5.0 is what I'm reading) says that device > should implement a handler to read offset 0x00-0x7F. Fair enough. I've since explored PNP0800 a bit, had a look at what Linux does in (apparently recent) acpi_cmos_rtc.c, asm-generic/rtc.h etc from mit.edu - much more complex and quirk-handling than ours - and soon realised how out of date my knowledge of any of this is; ACPI was at 3.0 last time I read much of the spec .. > > If so, you haven't to do battle with Time Lords :) with something people > > could add and load at own risk without messing with core kernel stuff. > > > > acpi_ibm should be a useful template, as it includes code to read CMOS > > bytes in the 0x60-0x6f range, presumably updated by the BIOS, whether > > opaquely or somehow via AML code I don't know. It uses rtcin() so has > > that scope in place. > > > > I'd still like to see your patch reject attempts to read or write to at > > least below 0x10. Even reading status register/s resets interrupts, and > > why would anyone need to mess with clock and/or timer regs via ACPI? > I assume it'd be the BIOS AML which would use my CMOS region handler; > it'd be a BIOS bug that reads/writes the clock regs. Fair enough again. My earlier impression was of a fix for a specific quirk for your HP, not realising you were implementing what is for FreeBSD a new handler for a new(er) ACPI feature, so ignore my musings. > > Maybe you could add a sysctl to limit access to some specific range? > I dunno... I really think what I have is the Right Thing To Do... > Someone else from freebsd-acpi@ suggested this approach. Maybe > someone versed in ACPI could clarify from the spec? I'd be happy to see more on-list information, but everyone's busy .. cheers, Ian