From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 15 03:43:09 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 255FBD94 for ; Sun, 15 Mar 2015 03:43:09 +0000 (UTC) Received: from nm7-vm4.bullet.mail.ne1.yahoo.com (nm7-vm4.bullet.mail.ne1.yahoo.com [98.138.91.167]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id DADBD302 for ; Sun, 15 Mar 2015 03:43:08 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426390835; bh=ld7THl5IKGwGEv2xyAlJ4O97WLJGuNdq7i1c3J9jJ38=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=I22DAyvQJb9uMzgKrn/rC5pGUO6f8dVFUtjHPJR5M5b2raOzpmXf03oby1Vwhagcx1aSl1NdsCP9OY/aYAQGVlWLd3WhstfJMAVfOulNd15GRl+5+Uc+QNctCMn3Yj1ClhKvxkRJCAiTWpUPjO7qqbj28/0w3EFhMgr6hcC0+9k= Received: from [98.138.100.117] by nm7.bullet.mail.ne1.yahoo.com with NNFMP; 15 Mar 2015 03:40:35 -0000 Received: from [98.138.226.59] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 15 Mar 2015 03:40:35 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 15 Mar 2015 03:40:35 -0000 X-Yahoo-Newman-Id: 569123.55907.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: YGUx5OYVM1lq5G3s6.h7M7ZpEG8r_3jk5thxTAE82VQSeP6 VrGzJyLZmC33SQN0ggk8pImEHhOAjqNOeHRO7naK7t5DZeveLth16h1NKTNM HpYEf8oXQL3Hmf184cuGJkBuEWwaoZ.T9k8.z4sMwRdt4UPdK4qJNEYAYy_d Dy8a6eYCj36Y9jh7i8Qu7YZ6gPgEsS2GyKFWV14B4OLbLuarkzHxWE0AJ95F 0HOwrMDnWtf3K5qQImwZ0YwKHVqZlxw98qmLCibZ0JioKZadSYu9YZ5Fo4O1 HOigTg.MmUTeQWu85mCAL8wRlrj_Vt5HS6qLHUcSXgjNbL9tep1KmsmxT38R O7Uz5aRuYwC08kfvs4N3r5Q.he5exkWnUW4jtKxUFi6.wS9YLhXjzfAMfHvj hBSKE.htC9vetTbYyOUb5DDBgwfIyohn9kQmZ35PHNmhhbdWMEl9MoBKQVCp 3yOP7FJZJPnf6b2TaspzaZSCzYfdrpQTP7xA96To_XSsTobpWpVF_1XxeTOB doeO36C5VsoPvGmW5WyWeJb0TH1FYVTcxsz67A7kwPgMj3QGu X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <5504FF32.3020202@att.net> Date: Sat, 14 Mar 2015 23:40:34 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith Subject: [PATCH] ACPI CMOS region support rev. 4 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> In-Reply-To: <54F9D7E6.4050807@att.net> Content-Type: multipart/mixed; boundary="------------090406000600090209050409" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 03:43:09 -0000 This is a multi-part message in MIME format. --------------090406000600090209050409 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit How about this one? :-) Sorry it's a week late. Anthony On 03/06/15 11:37, Anthony Jenkins wrote: > On 03/06/2015 06:49 AM, Ian Smith wrote: >> On Tue, 3 Mar 2015 11:45:49 -0500, Anthony Jenkins wrote: >> > On 03/01/2015 09:29 AM, Ian Smith wrote: >> [..] >> Regarding systems without ACPI loaded, or active: what happens when the >> below AcpiInstallAddressSpaceHandler() call fails, but returns 0? Would >> not that prevent rtc_start() from running atrtc_start() etc for non-ACPI >> clock initialisation and registration? > Good catch, there's technically no reason to bail on rtc_start() if I > fail to register the ACPI CMOS handler; it'll just never get called > (same as old behaviour). I'll change "Error" to "Warning" and remove > the return 0. > >> I suppose there's a global kernel variable for acpi_is_active ono? >> >> > +static int >> > rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) >> > { >> > >> > @@ -245,10 +323,17 @@ >> > int i; >> > >> > sc = device_get_softc(dev); >> > + sc->acpi_handle = acpi_get_handle(dev); >> > sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, >> > IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); >> > if (sc->port_res == NULL) >> > device_printf(dev, "Warning: Couldn't map I/O.\n"); >> > + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, >> > + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler, NULL, sc))) >> > + { >> > + device_printf(dev, "Error registering ACPI CMOS address space handler.\n"); >> > + return 0; >> > + } >> > atrtc_start(); >> > clock_register(dev, 1000000); >> > bzero(&sc->et, sizeof(struct eventtimer)); >> > @@ -286,6 +371,15 @@ >> > return(0); >> > } >> >> Might that not matter for detach, as you're not testing for return code? > Yeah I'd prefer to remember the failure to install the handler and > conditionally uninstall it in the detach method. > > I'll fix up the logging and add these suggestions this weekend. > > Thanks, > Anthony > >> > +static int atrtc_detach(device_t dev) >> > +{ >> > + struct atrtc_softc *sc; >> > + >> > + sc = device_get_softc(dev); >> > + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, >> > ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); >> > + return bus_generic_detach(dev); >> > +} >> >> cheers, Ian >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --------------090406000600090209050409 Content-Type: text/x-patch; name="atrtc_c_rev4.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="atrtc_c_rev4.diff" Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 279957) +++ sys/x86/isa/atrtc.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include "opt_isa.h" +#include "opt_acpi.h" #include #include @@ -53,9 +54,17 @@ #include #include "clock_if.h" +#include +#include +#include + #define RTC_LOCK do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0) #define RTC_UNLOCK do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0) +#define IO_DELAY() (void)inb(0x84) +#define IO_RTC_ADDR (IO_RTC + 0) +#define IO_RTC_DATA (IO_RTC + 1) + int atrtcclock_disable = 0; static int rtc_reg = -1; @@ -62,6 +71,12 @@ static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; static u_char rtc_statusb = RTCSB_24HR; +static unsigned int atrtc_verbose = 0; +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); +#define ATRTC_DBG_PRINTF(level, format, ...) \ + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) + /* * RTC support routines */ @@ -73,10 +88,10 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } val = inb(IO_RTC + 1); RTC_UNLOCK; @@ -89,16 +104,36 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } outb(IO_RTC + 1, val); - inb(0x84); + IO_DELAY(); RTC_UNLOCK; } +static void +acpi_cmos_read(ACPI_PHYSICAL_ADDRESS address, UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + buf[offset] = rtcin(address + offset) & 0xff; + } +} + +static void +acpi_cmos_write(ACPI_PHYSICAL_ADDRESS address, const UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + writertc(address + offset, buf[offset]); + } +} + static __inline int readrtc(int port) { @@ -161,9 +196,68 @@ struct resource *intr_res; void *intr_handler; struct eventtimer et; + ACPI_HANDLE acpi_handle; /* Handle of the PNP0B00 node */ + int acpi_handle_registered; /* 0 = acpi_handle not registered */ }; static int +acpi_check_rtc_byteaccess(int is_read, u_long addr) +{ + int retval = 1; /* Success */ + + if (is_read) { + /* Reading 0x0C will muck with interrupts */ + if (addr == 0x0C) + retval = 0; + } else { + if (!((addr <= 0x05 && (addr & 0x01)) || + (addr >= 0x30 && addr < 0x40))) + retval = 0; + } + return retval; +} + +static ACPI_STATUS +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, + UINT32 width, UINT64 *value, void *context, void *region_context) +{ + struct atrtc_softc *sc; + + sc = (struct atrtc_softc *)context; + if (!value || !sc) { + ATRTC_DBG_PRINTF(1, "%s: NULL parameter.\n", __FUNCTION__); + return AE_BAD_PARAMETER; + } + if (width > 32 || (width & 0x07) || address >= 64) { + ATRTC_DBG_PRINTF(1, "%s: Invalid width (%u) or address (0x%08lx).\n", + __FUNCTION__, width, address); + return AE_BAD_PARAMETER; + } + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) { + ATRTC_DBG_PRINTF(1, "%s: Bad CMOS %s access at address 0x%08lx.\n", + __FUNCTION__, function == ACPI_READ ? "read" : "write", address); + return AE_BAD_PARAMETER; + } + + switch (function) { + case ACPI_READ: + acpi_cmos_read(address, (UINT8 *)value, width >> 3); + break; + case ACPI_WRITE: + acpi_cmos_write(address, (const UINT8 *)value, + width >> 3); + break; + default: + ATRTC_DBG_PRINTF(1, "%s: Invalid function: %d.\n", __FUNCTION__, function); + return AE_BAD_PARAMETER; + } + ATRTC_DBG_PRINTF(1, "%s: %-5s%02u address=%04lx value=%08x\n", + __FUNCTION__, function == ACPI_READ ? "READ" : "WRITE", + width >> 3, address, *((UINT32 *)value)); + return AE_OK; +} + +static int rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) { @@ -245,10 +339,19 @@ int i; sc = device_get_softc(dev); + sc->acpi_handle = acpi_get_handle(dev); sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, + acpi_rtc_cmos_handler, NULL, sc))) + { + device_printf(dev, "Warning: Couldn't register ACPI CMOS address space handler.\n"); + /* I assume the softc was memset() to 0? */ + } else + sc->acpi_handle_registered = 1; atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); @@ -286,6 +389,17 @@ return(0); } +static int atrtc_detach(device_t dev) +{ + struct atrtc_softc *sc; + + sc = device_get_softc(dev); + if (sc->acpi_handle_registered) + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); + return bus_generic_detach(dev); +} + static int atrtc_resume(device_t dev) { @@ -366,7 +480,7 @@ /* Device interface */ DEVMETHOD(device_probe, atrtc_probe), DEVMETHOD(device_attach, atrtc_attach), - DEVMETHOD(device_detach, bus_generic_detach), + DEVMETHOD(device_detach, atrtc_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), /* XXX stop statclock? */ --------------090406000600090209050409-- From owner-freebsd-acpi@FreeBSD.ORG Sun Mar 15 19:59:22 2015 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CE102B3C for ; Sun, 15 Mar 2015 19:59:22 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B4114C1C for ; Sun, 15 Mar 2015 19:59:22 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2FJxMtI055655 for ; Sun, 15 Mar 2015 19:59:22 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 198603] [acpi] HP ProBook 430 G2: can't change brightness via acpi_hp and acpi_video Date: Sun, 15 Mar 2015 19:59:22 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 15 Mar 2015 19:59:22 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198603 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-acpi@FreeBSD.org -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 16 13:59:22 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A6614B40 for ; Mon, 16 Mar 2015 13:59:22 +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 B9FC72BF for ; Mon, 16 Mar 2015 13:59:21 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2GDx77S078550; Tue, 17 Mar 2015 00:59:07 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 17 Mar 2015 00:59:07 +1100 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: [PATCH] ACPI CMOS region support rev. 4 In-Reply-To: <5504FF32.3020202@att.net> Message-ID: <20150317001401.X22641@sola.nimnet.asn.au> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY=------------090406000600090209050409 Content-ID: <20150317001401.M22641@sola.nimnet.asn.au> Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 13:59:22 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --------------090406000600090209050409 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20150317001401.F22641@sola.nimnet.asn.au> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > How about this one? :-) Sorry it's a week late. +static unsigned int atrtc_verbose = 0; +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); +#define ATRTC_DBG_PRINTF(level, format, ...) \ + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) + A sysctl is good, but it needs to default to 1 if we're ever going to find out what various vendors are wanting to do with CMOS settings; anyone annoyed by any extra messages outside boot or suspend/resume could turn it off - after we've had the opportunity to get a report. I can only reiterate part of my message before last, of March 2nd: ======= > +static ACPI_STATUS > +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, > + UINT32 width, UINT64 *value, void *context, void *region_context) > +{ > + struct atrtc_softc *sc; > + > + sc = (struct atrtc_softc *)context; > + if (!value || !sc) > + return AE_BAD_PARAMETER; > + if (width > 32 || (width & 0x07) || address >= 64) > + return AE_BAD_PARAMETER; Width 0 passes, and address 61 width 32 passes. Maybe simpler: int bytes; /* or size, whatever, above */ bytes = width >> 3; and substitute 'bytes' subsequently, and here, perhaps: if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes)) > + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) > + return AE_BAD_PARAMETER; acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 bytes - or pass it 'bytes' also, and loop over each of them within? ======= Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). Sorry if I'm too much of a stickler for defensive programming .. cheers, Ian --------------090406000600090209050409 Content-Type: TEXT/X-PATCH; NAME=atrtc_c_rev4.diff Content-ID: <20150317001401.Q22641@sola.nimnet.asn.au> Content-Description: Content-Disposition: ATTACHMENT; FILENAME=atrtc_c_rev4.diff Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 279957) +++ sys/x86/isa/atrtc.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include "opt_isa.h" +#include "opt_acpi.h" #include #include @@ -53,9 +54,17 @@ #include #include "clock_if.h" +#include +#include +#include + #define RTC_LOCK do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0) #define RTC_UNLOCK do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0) +#define IO_DELAY() (void)inb(0x84) +#define IO_RTC_ADDR (IO_RTC + 0) +#define IO_RTC_DATA (IO_RTC + 1) + int atrtcclock_disable = 0; static int rtc_reg = -1; @@ -62,6 +71,12 @@ static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; static u_char rtc_statusb = RTCSB_24HR; +static unsigned int atrtc_verbose = 0; +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); +#define ATRTC_DBG_PRINTF(level, format, ...) \ + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) + /* * RTC support routines */ @@ -73,10 +88,10 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } val = inb(IO_RTC + 1); RTC_UNLOCK; @@ -89,16 +104,36 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } outb(IO_RTC + 1, val); - inb(0x84); + IO_DELAY(); RTC_UNLOCK; } +static void +acpi_cmos_read(ACPI_PHYSICAL_ADDRESS address, UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + buf[offset] = rtcin(address + offset) & 0xff; + } +} + +static void +acpi_cmos_write(ACPI_PHYSICAL_ADDRESS address, const UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + writertc(address + offset, buf[offset]); + } +} + static __inline int readrtc(int port) { @@ -161,9 +196,68 @@ struct resource *intr_res; void *intr_handler; struct eventtimer et; + ACPI_HANDLE acpi_handle; /* Handle of the PNP0B00 node */ + int acpi_handle_registered; /* 0 = acpi_handle not registered */ }; static int +acpi_check_rtc_byteaccess(int is_read, u_long addr) +{ + int retval = 1; /* Success */ + + if (is_read) { + /* Reading 0x0C will muck with interrupts */ + if (addr == 0x0C) + retval = 0; + } else { + if (!((addr <= 0x05 && (addr & 0x01)) || + (addr >= 0x30 && addr < 0x40))) + retval = 0; + } + return retval; +} + +static ACPI_STATUS +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, + UINT32 width, UINT64 *value, void *context, void *region_context) +{ + struct atrtc_softc *sc; + + sc = (struct atrtc_softc *)context; + if (!value || !sc) { + ATRTC_DBG_PRINTF(1, "%s: NULL parameter.\n", __FUNCTION__); + return AE_BAD_PARAMETER; + } + if (width > 32 || (width & 0x07) || address >= 64) { + ATRTC_DBG_PRINTF(1, "%s: Invalid width (%u) or address (0x%08lx).\n", + __FUNCTION__, width, address); + return AE_BAD_PARAMETER; + } + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) { + ATRTC_DBG_PRINTF(1, "%s: Bad CMOS %s access at address 0x%08lx.\n", + __FUNCTION__, function == ACPI_READ ? "read" : "write", address); + return AE_BAD_PARAMETER; + } + + switch (function) { + case ACPI_READ: + acpi_cmos_read(address, (UINT8 *)value, width >> 3); + break; + case ACPI_WRITE: + acpi_cmos_write(address, (const UINT8 *)value, + width >> 3); + break; + default: + ATRTC_DBG_PRINTF(1, "%s: Invalid function: %d.\n", __FUNCTION__, function); + return AE_BAD_PARAMETER; + } + ATRTC_DBG_PRINTF(1, "%s: %-5s%02u address=%04lx value=%08x\n", + __FUNCTION__, function == ACPI_READ ? "READ" : "WRITE", + width >> 3, address, *((UINT32 *)value)); + return AE_OK; +} + +static int rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) { @@ -245,10 +339,19 @@ int i; sc = device_get_softc(dev); + sc->acpi_handle = acpi_get_handle(dev); sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, + acpi_rtc_cmos_handler, NULL, sc))) + { + device_printf(dev, "Warning: Couldn't register ACPI CMOS address space handler.\n"); + /* I assume the softc was memset() to 0? */ + } else + sc->acpi_handle_registered = 1; atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); @@ -286,6 +389,17 @@ return(0); } +static int atrtc_detach(device_t dev) +{ + struct atrtc_softc *sc; + + sc = device_get_softc(dev); + if (sc->acpi_handle_registered) + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); + return bus_generic_detach(dev); +} + static int atrtc_resume(device_t dev) { @@ -366,7 +480,7 @@ /* Device interface */ DEVMETHOD(device_probe, atrtc_probe), DEVMETHOD(device_attach, atrtc_attach), - DEVMETHOD(device_detach, bus_generic_detach), + DEVMETHOD(device_detach, atrtc_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), /* XXX stop statclock? */ --------------090406000600090209050409-- From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 16 15:02:58 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id D6040DF2 for ; Mon, 16 Mar 2015 15:02:58 +0000 (UTC) Received: from nm8-vm2.bullet.mail.ne1.yahoo.com (nm8-vm2.bullet.mail.ne1.yahoo.com [98.138.90.156]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 997FBE2D for ; Mon, 16 Mar 2015 15:02:58 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426518028; bh=CbAl96ukmF+qQcOUR58a2IvFqR6P1bjv6lLSvPTe5Qo=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=IaJ12VWR7ObZHn2TJtwZJxHc6sF4GR351uJgBLO5fb+LQQTbrsX+q9JfTSf9T2vzmiJoegIn2G35ou2xnYT/kC9qC/SNN+4hMe4B5iYAzLBlY71KzzIYW+zsXp5nhBF6Pcx2vSroxwjKTZyUbDylPYdMmL/peNfz24S1INx6j8A= Received: from [98.138.101.128] by nm8.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 15:00:28 -0000 Received: from [98.138.226.30] by tm16.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 15:00:28 -0000 Received: from [127.0.0.1] by smtp201.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 15:00:28 -0000 X-Yahoo-Newman-Id: 182340.16851.bm@smtp201.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: GiGW6AwVM1kY2qJhIN0yWzAEc4TmlI.YuTPGBtWMAj8aHpY 8qfDg6rx.YZulATnucz12i7RHRpHNlfYntdzBBT2nvwFOBKKsdMSu4QDN65X pg6OYjpGCmWO8IAi2nKm6fwOIGUhY9C6lM5g8dU4rFa_vifg2vatsR3DMOiL C1K_dHfbBu5wdF3kHzK_cNAHD4uAHQBZ0yl_M8W4pJeOXeW0JUZscwfRZf2e bH2xe0GDHm6kqB6aO_7VHAvQzsLJoKcalMfbBF_uTOAnxNI3GQgaB4jyXs9t R0r1ojOnZIHP96Bxg1DbkhAJzpwybhDNtk1gcdxNGQ1aNPBYpOo2Hpy_J4FE lcyBUqScy31uX3YLx4s3qorYQC3AQ3kursNOx04vMEeqOZwHpX5Kv5Fc9bJu dkTQycX.OywVvzXTs54BnLfMSHte9r4EXSrhwmcdcWNEQcSTu9gRd1H_RYPk eH1ZLJYG8irikebcsxRICO3.cqQfydWnj9a4hB9.9vl11ca4OlhlLtSuBd7o cW0vqjOQ4CaKOI_TlEl8JahyQvv.e9wKbV7ukg1zcmK4h3LFr X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <5506F00A.3030708@att.net> Date: Mon, 16 Mar 2015 11:00:26 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 4 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> In-Reply-To: <20150317001401.X22641@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:02:58 -0000 On 03/16/2015 09:59 AM, Ian Smith wrote: > On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > > > How about this one? :-) Sorry it's a week late. > > +static unsigned int atrtc_verbose = 0; > +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, > + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); > +#define ATRTC_DBG_PRINTF(level, format, ...) \ > + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) > + > > A sysctl is good, but it needs to default to 1 if we're ever going to > find out what various vendors are wanting to do with CMOS settings; > anyone annoyed by any extra messages outside boot or suspend/resume > could turn it off - after we've had the opportunity to get a report. I'd actually prefer debug level to be compile-time (there's no real need for it to be runtime), but I really don't want to add a config(5) knob (I can of course). > I can only reiterate part of my message before last, of March 2nd: > > ======= >> +static ACPI_STATUS >> +acpi_rtc_cmos_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address, >> + UINT32 width, UINT64 *value, void *context, void *region_context) >> +{ >> + struct atrtc_softc *sc; >> + >> + sc = (struct atrtc_softc *)context; >> + if (!value || !sc) >> + return AE_BAD_PARAMETER; >> + if (width > 32 || (width & 0x07) || address >= 64) >> + return AE_BAD_PARAMETER; > Width 0 passes, and address 61 width 32 passes. Maybe simpler: > int bytes; /* or size, whatever, above */ > bytes = width >> 3; That should probably be bytes = (width + 7) >>3; or bytes = (width + 7) / 8; /* Integer division more expensive on x86? */ because width == 1 would result in bytes = 0. > and substitute 'bytes' subsequently, and here, perhaps: > > if (bytes < 1 || bytes > 4 || (width & 0x07) || address > (64 - bytes)) > >> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) >> + return AE_BAD_PARAMETER; > acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 > bytes - or pass it 'bytes' also, and loop over each of them within? > ======= > > Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from > 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write > to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). Right, this is an (incorrect) hybrid of a few attempts, probably from around the time I lost my SSD and only had a single backup copy of my work to go from. In one revision I had disallowed all multibyte accesses (width > 8) since IMHO it was more consistent/correct with the suggested locking. I wasn't ignoring your suggestion, just making one or a few changes at a time (generally the simpler ones). I /believe/ the ACPI spec disallows requests for width=0. Looking at ACPIspec50.pdf, the smallest OperationRegion that can be defined is 1 byte, and the smallest Field within an OpRegion is 1 bit, and all accesses to an OpRegion occur via Fields (Section 19.5.96 OperationRegion (Declare Operation Region)). Doesn't hurt to check tho. Also OpRegions operations are synchronized, so I at least don't have to worry about AML accessing CMOS all willy-nilly. > Sorry if I'm too much of a stickler for defensive programming .. Oh no problem, I can handle a bit of criticism :-) Anthony > > cheers, Ian > > > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 16 15:53:00 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 5BFFC614 for ; Mon, 16 Mar 2015 15:53:00 +0000 (UTC) Received: from nm1-vm6.bullet.mail.ne1.yahoo.com (nm1-vm6.bullet.mail.ne1.yahoo.com [98.138.91.253]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1615980E for ; Mon, 16 Mar 2015 15:52:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426521061; bh=fReklZ+q8BPfXzMVwpYPkmdoqBmHLAyVNaTjxUJqD84=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=z07aTJEtzyY0dXswaRhYdypI8/hYypCSLiw/TYaXW8QoRO9pVCUdkMptZ/H3VA386yraRd6F6VtArEUwl8W27sI+od+vn3nlrh1+dN/f1QWD9JHdhVseFE5D5bKxIQxxN9NQ9lGEzkTyzndIUpt6eDc8v2slV+QD7TuTmS4uksM= Received: from [98.138.100.111] by nm1.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 15:51:01 -0000 Received: from [98.138.84.39] by tm100.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 15:51:01 -0000 Received: from [127.0.0.1] by smtp107.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 15:51:01 -0000 X-Yahoo-Newman-Id: 897471.32924.bm@smtp107.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9IkgwB4VM1nL_SeyHpmQvOt4793nR_.dQfBJwBnMcC5v1p7 LqahrPt0G6.uaKhQJR0WqnLdMpFHCnujbmZ1w81HVUtgcWUsGBmomodXUNN_ wMplGuisNou94nwUYG0BWQuOnMjQk_pSdrlFXVaen1q8afYgzDAZXx6W8M_r yW7T0QWzfO7wU3K9Gto0OD9uu.peCLv5kdndS2Ah_SUg.QDVsu3VLGbwAQda hD5tO5XfFyZahzLqcBqx5T_S5Q1VDZSj511GMj89N9gnKJH3ofHk2H._Q2zf eV4fov2HdT8o0AMWwWmZFJNf974EBvhUxxL4Z6VsmZqh2ZO.u9aakdVMcz_o rJmaSmEOPYn5OrCL8_eh9nl.N6CdKwIR.ibXJ4ihcmhj3LwVSnTWsm3oo4PL mB__AmLqnmoGSm.3M3qkS64QkklHlq2nPL0nKX__dAWYsWj3tq9__ANOobTG oCoWpBgbYBh6um9.Ru55VReCbAgAWrpDnMmoKQYUwEeb4W9Sod5bhUNOfHNA RB4jKa3kE8RrIJr0zUqihDbSMd9LJ61OjprOIgXG88g76kYo1 X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <5506FBE3.1000009@att.net> Date: Mon, 16 Mar 2015 11:50:59 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 4 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> In-Reply-To: <5506F00A.3030708@att.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 15:53:00 -0000 On 03/16/2015 11:00 AM, Anthony Jenkins wrote: > On 03/16/2015 09:59 AM, Ian Smith wrote: >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) >>> + return AE_BAD_PARAMETER; >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 >> bytes - or pass it 'bytes' also, and loop over each of them within? >> ======= >> >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). > Right, this is an (incorrect) hybrid of a few attempts, probably from > around the time I lost my SSD and only had a single backup copy of my > work to go from. In one revision I had disallowed all multibyte > accesses (width > 8) since IMHO it was more consistent/correct with the > suggested locking. I wasn't ignoring your suggestion, just making one > or a few changes at a time (generally the simpler ones). Okay now I remember why I was reluctant to do this - suppose ACPIBIOS does a multibyte op on a set of bytes whose last byte fails acpi_check_rtc_byteaccess(). I will have already performed n-1 accesses. At one point I had a revision (acpi_check_rtc_access()?) that permitted/denied the entire request (it took the starting address and byte length), but I guess that got lost too. I'll just recreate it... Anthony > >> cheers, Ian >> >> >> _______________________________________________ >> freebsd-acpi@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi >> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 16 17:49:29 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 2F4EDBC8 for ; Mon, 16 Mar 2015 17:49:29 +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 F294D8CF for ; Mon, 16 Mar 2015 17:49:27 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2GHnIFR086406; Tue, 17 Mar 2015 04:49:18 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 17 Mar 2015 04:49:18 +1100 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: [PATCH] ACPI CMOS region support rev. 4 In-Reply-To: <5506FBE3.1000009@att.net> Message-ID: <20150317041624.K22641@sola.nimnet.asn.au> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 17:49:29 -0000 On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote: > On 03/16/2015 11:00 AM, Anthony Jenkins wrote: > > On 03/16/2015 09:59 AM, Ian Smith wrote: > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) > >>> + return AE_BAD_PARAMETER; > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 > >> bytes - or pass it 'bytes' also, and loop over each of them within? > >> ======= > >> > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). > > Right, this is an (incorrect) hybrid of a few attempts, probably from > > around the time I lost my SSD and only had a single backup copy of my > > work to go from. In one revision I had disallowed all multibyte > > accesses (width > 8) since IMHO it was more consistent/correct with the > > suggested locking. I wasn't ignoring your suggestion, just making one > > or a few changes at a time (generally the simpler ones). > > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS > does a multibyte op on a set of bytes whose last byte fails > acpi_check_rtc_byteaccess(). I will have already performed n-1 > accesses. At one point I had a revision (acpi_check_rtc_access()?) that > permitted/denied the entire request (it took the starting address and > byte length), but I guess that got lost too. I'll just recreate it... Yep, validating all access before doing any sounds like the way to go. Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07), so non-multiples of 8 bits are invalidated anyway. You should still check that width (or bytes) > 0, even if 0 should never be passed. I guess the Big Kids will start playing once this hits bugzilla? :) cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 16 19:53:52 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 6CEB44F1 for ; Mon, 16 Mar 2015 19:53:52 +0000 (UTC) Received: from nm3-vm5.bullet.mail.ne1.yahoo.com (nm3-vm5.bullet.mail.ne1.yahoo.com [98.138.91.225]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B917A61 for ; Mon, 16 Mar 2015 19:53:51 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426535491; bh=jpz5pZjDeQp+IbbHyarDHdOS7J2J7s1umAISPBLxto8=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=k452WzICJO8uh8H7PGPewviqNdAvXqDAvs2Vso1XsHQ9WjlS1X1Wx4ybrEjScUX7RzJ10h2dsu3LbIGM+cSOqItUngfdFITGqbn0VfQBt0IpKWNf8VFNWbUvSP8QznGJxndWTq3ESTc12kknYZiooR0EJEe58vszEMWjP+tn2pA= Received: from [98.138.100.114] by nm3.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 19:51:31 -0000 Received: from [98.138.226.59] by tm105.bullet.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 19:51:31 -0000 Received: from [127.0.0.1] by smtp210.mail.ne1.yahoo.com with NNFMP; 16 Mar 2015 19:51:31 -0000 X-Yahoo-Newman-Id: 640935.75168.bm@smtp210.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 9sXNhLUVM1k_my9GEGD3euXLhzVyh6TdzNEQ4U8St.Ow4Dm KBWth5kg9nPrRl_H39EUXBmZCg3.CsjE1mOcAUWK3xbfTYQOKr_2lcu4qf9X fXGHf_YmptbJu6J.fKV.4ET4O9rHj_9IWRIvL2KbXw_HBgM68aPJ2K5enbzB j_KLb5cssEpM_8cT16OKaLVrvj09KG5OMo6Hutuwm_pTdJYIzPaxtDH9INUx JkC7zUYp1GPB_M6sIv.RxsdQ4vdJCecnQZe8.zYzskL.Tr5SS7DMhm7tEVSP 9TQeB9WWYrUJdZWwkpXZ1XAbChmczRA55J3BBFQ7llWFnbDKQPLXvyOonJ_3 VGxQo7CGA5OAhPQkdxaVFkIa2vBcqzj0i87Ogbtw2eNYcJrSyd2Ph6ulY7bN wqLST51qesynosOwC3hNNByH0PdbcTuMvtP5jF.Gjro4KakZ3F2ReG45MXOd le0UqRYdx6dpu1qh.La2HUINWp6Xm62gP2Z2UU7MnTHZuJDzma0yCtYoHJkl TOZvUCvLwabzXJwQVb0alL4oCHnUimQGDaLuNgEG7UsOSZWsi X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <55073442.5060005@att.net> Date: Mon, 16 Mar 2015 15:51:30 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith Subject: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> In-Reply-To: <20150317041624.K22641@sola.nimnet.asn.au> Content-Type: multipart/mixed; boundary="------------060805080104030201010503" Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 19:53:52 -0000 This is a multi-part message in MIME format. --------------060805080104030201010503 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit On 03/16/2015 01:49 PM, Ian Smith wrote: > On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote: > > On 03/16/2015 11:00 AM, Anthony Jenkins wrote: > > > On 03/16/2015 09:59 AM, Ian Smith wrote: > > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) > > >>> + return AE_BAD_PARAMETER; > > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 > > >> bytes - or pass it 'bytes' also, and loop over each of them within? > > >> ======= > > >> > > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from > > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write > > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). > > > Right, this is an (incorrect) hybrid of a few attempts, probably from > > > around the time I lost my SSD and only had a single backup copy of my > > > work to go from. In one revision I had disallowed all multibyte > > > accesses (width > 8) since IMHO it was more consistent/correct with the > > > suggested locking. I wasn't ignoring your suggestion, just making one > > > or a few changes at a time (generally the simpler ones). > > > > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS > > does a multibyte op on a set of bytes whose last byte fails > > acpi_check_rtc_byteaccess(). I will have already performed n-1 > > accesses. At one point I had a revision (acpi_check_rtc_access()?) that > > permitted/denied the entire request (it took the starting address and > > byte length), but I guess that got lost too. I'll just recreate it... > > Yep, validating all access before doing any sounds like the way to go. > > Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07), > so non-multiples of 8 bits are invalidated anyway. You should still > check that width (or bytes) > 0, even if 0 should never be passed. Oh yeah, forgot about that! > I guess the Big Kids will start playing once this hits bugzilla? :) I'm just glad I get to learn how to commit stuff to FreeBSD. Here's another iteration...comments welcome. Think I got (most) everything in there. I need to unit test acpi_check_rtc_access() to make sure it DTRT. Anthony > cheers, Ian > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" --------------060805080104030201010503 Content-Type: text/x-patch; name="atrtc_c_rev5.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="atrtc_c_rev5.diff" Index: sys/x86/isa/atrtc.c =================================================================== --- sys/x86/isa/atrtc.c (revision 279957) +++ sys/x86/isa/atrtc.c (working copy) @@ -31,6 +31,7 @@ __FBSDID("$FreeBSD$"); #include "opt_isa.h" +#include "opt_acpi.h" #include #include @@ -53,9 +54,17 @@ #include #include "clock_if.h" +#include +#include +#include + #define RTC_LOCK do { if (!kdb_active) mtx_lock_spin(&clock_lock); } while (0) #define RTC_UNLOCK do { if (!kdb_active) mtx_unlock_spin(&clock_lock); } while (0) +#define IO_DELAY() (void)inb(0x84) +#define IO_RTC_ADDR (IO_RTC + 0) +#define IO_RTC_DATA (IO_RTC + 1) + int atrtcclock_disable = 0; static int rtc_reg = -1; @@ -62,6 +71,16 @@ static u_char rtc_statusa = RTCSA_DIVIDER | RTCSA_NOPROF; static u_char rtc_statusb = RTCSB_24HR; +#ifndef ATRTC_VERBOSE +#define ATRTC_VERBOSE 1 +#endif + +static unsigned int atrtc_verbose = ATRTC_VERBOSE; +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); +#define ATRTC_DBG_PRINTF(level, format, ...) \ + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) + /* * RTC support routines */ @@ -73,10 +92,10 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } val = inb(IO_RTC + 1); RTC_UNLOCK; @@ -89,16 +108,36 @@ RTC_LOCK; if (rtc_reg != reg) { - inb(0x84); + IO_DELAY(); outb(IO_RTC, reg); rtc_reg = reg; - inb(0x84); + IO_DELAY(); } outb(IO_RTC + 1, val); - inb(0x84); + IO_DELAY(); RTC_UNLOCK; } +static void +acpi_cmos_read(ACPI_PHYSICAL_ADDRESS address, UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + buf[offset] = rtcin(address + offset) & 0xff; + } +} + +static void +acpi_cmos_write(ACPI_PHYSICAL_ADDRESS address, const UINT8 *buf, UINT32 buflen) +{ + UINT32 offset; + + for (offset = 0; offset < buflen; ++offset) { + writertc(address + offset, buf[offset]); + } +} + static __inline int readrtc(int port) { @@ -161,9 +200,72 @@ struct resource *intr_res; void *intr_handler; struct eventtimer et; + ACPI_HANDLE acpi_handle; /* Handle of the PNP0B00 node */ + int acpi_handle_registered; /* 0 = acpi_handle not registered */ }; static int +acpi_check_rtc_access(int is_read, u_long addr, u_long len) +{ + int retval = 1; /* Success */ + + if (is_read) { + /* Reading 0x0C will muck with interrupts */ + if (addr + len - 1 >= 0x0C && addr <= 0x0c) + retval = 0; + } else { + /* Allow single-byte writes to alarm registers and + * addr >= 0x30, else deny. + */ + if (!((len == 1 && (addr <= 5 && (addr & 1))) || addr >= 0x30)) + retval = 0; + } + return retval; +} + +static ACPI_STATUS +acpi_rtc_cmos_handler(UINT32 func, ACPI_PHYSICAL_ADDRESS addr, + UINT32 bitwidth, UINT64 *value, void *context, void *region_context) +{ + struct atrtc_softc *sc; + UINT32 bytewidth = bitwidth >> 3; + + sc = (struct atrtc_softc *)context; + if (!value || !sc) { + ATRTC_DBG_PRINTF(1, "NULL parameter.\n"); + return AE_BAD_PARAMETER; + } + if (bitwidth == 0 || bitwidth > 32 || (bitwidth & 0x07) || + addr + bytewidth - 1 > 63) { + ATRTC_DBG_PRINTF(1, + "Invalid bitwidth (%u) or addr (0x%08lx).\n", + bitwidth, addr); + return AE_BAD_PARAMETER; + } + if (!acpi_check_rtc_access(func == ACPI_READ, addr, bytewidth)) { + ATRTC_DBG_PRINTF(1, "Bad CMOS %s access at addr 0x%08lx.\n", + func == ACPI_READ ? "read" : "write", addr); + return AE_BAD_PARAMETER; + } + + switch (func) { + case ACPI_READ: + acpi_cmos_read(addr, (UINT8 *)value, bytewidth); + break; + case ACPI_WRITE: + acpi_cmos_write(addr, (const UINT8 *)value, bytewidth); + break; + default: + ATRTC_DBG_PRINTF(1, "Invalid function: %d.\n", func); + return AE_BAD_PARAMETER; + } + ATRTC_DBG_PRINTF(1, "%-5s%02u addr=%04lx val=%08x\n", + func == ACPI_READ ? "READ" : "WRITE", bytewidth, + addr, *((UINT32 *)value)); + return AE_OK; +} + +static int rtc_start(struct eventtimer *et, sbintime_t first, sbintime_t period) { @@ -245,10 +347,19 @@ int i; sc = device_get_softc(dev); + sc->acpi_handle = acpi_get_handle(dev); sc->port_res = bus_alloc_resource(dev, SYS_RES_IOPORT, &sc->port_rid, IO_RTC, IO_RTC + 1, 2, RF_ACTIVE); if (sc->port_res == NULL) device_printf(dev, "Warning: Couldn't map I/O.\n"); + if (ACPI_FAILURE(AcpiInstallAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, + acpi_rtc_cmos_handler, NULL, sc))) + { + device_printf(dev, "Warning: Couldn't register ACPI CMOS address space handler.\n"); + /* I assume the softc was memset() to 0? */ + } else + sc->acpi_handle_registered = 1; atrtc_start(); clock_register(dev, 1000000); bzero(&sc->et, sizeof(struct eventtimer)); @@ -286,6 +397,17 @@ return(0); } +static int atrtc_detach(device_t dev) +{ + struct atrtc_softc *sc; + + sc = device_get_softc(dev); + if (sc->acpi_handle_registered) + AcpiRemoveAddressSpaceHandler(sc->acpi_handle, + ACPI_ADR_SPACE_CMOS, acpi_rtc_cmos_handler); + return bus_generic_detach(dev); +} + static int atrtc_resume(device_t dev) { @@ -366,7 +488,7 @@ /* Device interface */ DEVMETHOD(device_probe, atrtc_probe), DEVMETHOD(device_attach, atrtc_attach), - DEVMETHOD(device_detach, bus_generic_detach), + DEVMETHOD(device_detach, atrtc_detach), DEVMETHOD(device_shutdown, bus_generic_shutdown), DEVMETHOD(device_suspend, bus_generic_suspend), /* XXX stop statclock? */ --------------060805080104030201010503-- From owner-freebsd-acpi@FreeBSD.ORG Mon Mar 16 23:36:07 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [IPv6:2001:1900:2254:206a::19:2]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 31CEDF4F for ; Mon, 16 Mar 2015 23:36:07 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id D57592FC0; Mon, 16 Mar 2015 23:36:06 +0000 (UTC) Message-ID: <550768E6.6000801@FreeBSD.org> Date: Mon, 16 Mar 2015 19:36:06 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Anthony Jenkins , Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> In-Reply-To: <55073442.5060005@att.net> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 16 Mar 2015 23:36:07 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/16/2015 15:51, Anthony Jenkins wrote: > On 03/16/2015 01:49 PM, Ian Smith wrote: >> On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote: >>> On 03/16/2015 11:00 AM, Anthony Jenkins wrote: >>>> On 03/16/2015 09:59 AM, Ian Smith wrote: >>>>> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: >>>>>> + if (!acpi_check_rtc_byteaccess(function == >>>>>> ACPI_READ, address)) + return >>>>>> AE_BAD_PARAMETER; >>>>> acpi_check_rtc_byteaccess() needs to be called per byte of >>>>> 1, 2 or 4 bytes - or pass it 'bytes' also, and loop over >>>>> each of them within? ======= >>>>> >>>>> Otherwise (for example) a 2 byte read from 0x0b or 4 byte >>>>> read from 0x09-0x0b will read 0x0c (clearing interrupts), >>>>> or a 2 or 4 byte write to (say) 0x01 will also write to >>>>> 0x02 and 0x04 (clobbering the time). >>>> Right, this is an (incorrect) hybrid of a few attempts, >>>> probably from around the time I lost my SSD and only had a >>>> single backup copy of my work to go from. In one revision I >>>> had disallowed all multibyte accesses (width > 8) since IMHO >>>> it was more consistent/correct with the suggested locking. I >>>> wasn't ignoring your suggestion, just making one or a few >>>> changes at a time (generally the simpler ones). >>> >>> Okay now I remember why I was reluctant to do this - suppose >>> ACPIBIOS does a multibyte op on a set of bytes whose last byte >>> fails acpi_check_rtc_byteaccess(). I will have already >>> performed n-1 accesses. At one point I had a revision >>> (acpi_check_rtc_access()?) that permitted/denied the entire >>> request (it took the starting address and byte length), but I >>> guess that got lost too. I'll just recreate it... >> >> Yep, validating all access before doing any sounds like the way >> to go. >> >> Also, bytes = width >> 3 is ok, since you then affirm !(width & >> 0x07), so non-multiples of 8 bits are invalidated anyway. You >> should still check that width (or bytes) > 0, even if 0 should >> never be passed. > > Oh yeah, forgot about that! > >> I guess the Big Kids will start playing once this hits bugzilla? >> :) > > I'm just glad I get to learn how to commit stuff to FreeBSD. > > Here's another iteration...comments welcome. Think I got (most) > everything in there. I need to unit test acpi_check_rtc_access() > to make sure it DTRT. I see that there are several minor style(9) bugs but the most serious problem is this patch makes atrtc.c dependent on ACPI and it practically kills off APM support. Please make it optional (hint: sys/conf/files* and sys/conf/options*) although I don't mind killing off APM support. ;-) Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVB2jgAAoJEHyflib82/FG2i4IAIVjf2fN6HcxVBzWbB5SWBGl d4ZircYjOkq5ld8jqVBuZP+En5Jm94JABo1Hp3XV4z8GNzCT29jB8STh4WmpU8Zu A6kURXJjAPyUZbbQKtRr1YzTOfzttUNBBnPPbFvyAZG0vLEjCwZnx/2t7yrO2A/I 7PgbW5Qtl1TTRYux/eF6zFEWo2nPrK70Rr8dKCYTUlJnYorz3YVuSkM1PrjJUjom 6C0t3N3X5BxziuW/NRwWWWCf2EOkAR3Mdefo/eFASm8+n4GTCpxflnWPuy6NjIYY 1NSmqGurTcFoyQ9igzl7J8gWteqwaPMjlpAp0GCU1ADpkhrBmcU7dFK9C7jcOaE= =ZKAN -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 17 04:11:17 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 001971ED for ; Tue, 17 Mar 2015 04:11:16 +0000 (UTC) Received: from nm11-vm3.bullet.mail.gq1.yahoo.com (nm11-vm3.bullet.mail.gq1.yahoo.com [98.136.218.158]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B9DAC9B8 for ; Tue, 17 Mar 2015 04:11:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426565158; bh=/8xxFRn4VO2aDKl4YRkHv0wMic9VQo+KMHoCrz3vHoY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=f/kJnEAwY41+FLaeLM+7iMmO+d0zwe/2Y4WgY/e2aJFrJOuClr11bckvAqxAklYWH7keekQ8J3kMuUUY9VJw8/bSVUpsxP7V1zWuONOhX6w8R28WF+8rKzlXsAy8lVT2pIgmbZRcvbpvoGdu9nTycpyWeEZJahrc4c3UHjcrSw4= Received: from [216.39.60.180] by nm11.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2015 04:05:58 -0000 Received: from [98.138.226.62] by tm16.bullet.mail.gq1.yahoo.com with NNFMP; 17 Mar 2015 04:05:58 -0000 Received: from [127.0.0.1] by smtp213.mail.ne1.yahoo.com with NNFMP; 17 Mar 2015 04:05:58 -0000 X-Yahoo-Newman-Id: 468124.31228.bm@smtp213.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: QqU2RjgVM1l4gaAAv6lgV8VLjJ_P9MuMkDZQg5Boi6FInrK AWcskpJv6sTlbpsbmsB7VM.vDPHdkXat5P10NXfgWbjQkZfAkGyyfhRJZzUI X9wuFWDc3uRkAA9fTWltiyP5jgb0MTSVCn.up58vzKAhFjXwIa0wX06wODtm gfHn8WXCKEL3c7LSHyR3SbmJqEBvByUPX0GRHXeZTN1MSNKqlPyRuhyrkQyn 2B3qpsQoueZN1Ib0InrandrJZPyD6QIPVrv1tJm2hojsHc583crxebdW7_rK kelsHICas8ZeDmNb8ksYvHQPCpY4O59SgDOIuXJIMyvc4wdTCRhTvZtJwQaW DzFa63ehuO2JJTF7v1QEyy617HXu9PJOjaH7xrqlN7JXFtkEoEoUu6Spa81r EwI3jnfuPAaRiknkl8Hj2HLJWqEZxAUCWPZygvpEnySqjT.dMAXyYPmDPRrN 6oSqBhXTbUhyHrTT.awwqTAzGHiBoSRDDwW6NinNh4DDKypxtGcP43bq94J3 XAs5an.TLuZrQGYw8OMVlSX0V23bSOrmfxG4CZkg.BLZZgwkZ X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <5507A820.5000707@att.net> Date: Tue, 17 Mar 2015 00:05:52 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Jung-uk Kim , Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <550768E6.6000801@FreeBSD.org> In-Reply-To: <550768E6.6000801@FreeBSD.org> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 04:11:17 -0000 On 03/16/15 19:36, Jung-uk Kim wrote: > On 03/16/2015 15:51, Anthony Jenkins wrote: > > On 03/16/2015 01:49 PM, Ian Smith wrote: > >> On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote: > >>> On 03/16/2015 11:00 AM, Anthony Jenkins wrote: > >>>> On 03/16/2015 09:59 AM, Ian Smith wrote: > >>>>> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > >>>>>> + if (!acpi_check_rtc_byteaccess(function =3D=3D > >>>>>> ACPI_READ, address)) + return > >>>>>> AE_BAD_PARAMETER; > >>>>> acpi_check_rtc_byteaccess() needs to be called per byte of > >>>>> 1, 2 or 4 bytes - or pass it 'bytes' also, and loop over > >>>>> each of them within? =3D=3D=3D=3D=3D=3D=3D > >>>>> > >>>>> Otherwise (for example) a 2 byte read from 0x0b or 4 byte > >>>>> read from 0x09-0x0b will read 0x0c (clearing interrupts), > >>>>> or a 2 or 4 byte write to (say) 0x01 will also write to > >>>>> 0x02 and 0x04 (clobbering the time). > >>>> Right, this is an (incorrect) hybrid of a few attempts, > >>>> probably from around the time I lost my SSD and only had a > >>>> single backup copy of my work to go from. In one revision I > >>>> had disallowed all multibyte accesses (width > 8) since IMHO > >>>> it was more consistent/correct with the suggested locking. I > >>>> wasn't ignoring your suggestion, just making one or a few > >>>> changes at a time (generally the simpler ones). > >>> > >>> Okay now I remember why I was reluctant to do this - suppose > >>> ACPIBIOS does a multibyte op on a set of bytes whose last byte > >>> fails acpi_check_rtc_byteaccess(). I will have already > >>> performed n-1 accesses. At one point I had a revision > >>> (acpi_check_rtc_access()?) that permitted/denied the entire > >>> request (it took the starting address and byte length), but I > >>> guess that got lost too. I'll just recreate it... > >> > >> Yep, validating all access before doing any sounds like the way > >> to go. > >> > >> Also, bytes =3D width >> 3 is ok, since you then affirm !(width & > >> 0x07), so non-multiples of 8 bits are invalidated anyway. You > >> should still check that width (or bytes) > 0, even if 0 should > >> never be passed. > > > Oh yeah, forgot about that! > > >> I guess the Big Kids will start playing once this hits bugzilla? > >> :) > > > I'm just glad I get to learn how to commit stuff to FreeBSD. > > > Here's another iteration...comments welcome. Think I got (most) > > everything in there. I need to unit test acpi_check_rtc_access() > > to make sure it DTRT. > > I see that there are several minor style(9) bugs Ahh... style(9) is what I was looking for, thanks. Yeah I was hoping someone would point me to FreeBSD's official coding style guide. > but the most serious > problem is this patch makes atrtc.c dependent on ACPI and it > practically kills off APM support. Not quite sure what you mean here... do you mean a non-ACPI build of the kernel would fail to compile atrtc(4)? Yeah I can fix that. > Please make it optional (hint: > sys/conf/files* and sys/conf/options*) although I don't mind killing > off APM support. ;-) Well I'd just make the ACPI CMOS handler code conditional on ACPI being enabled in config(5)... is that what you're looking for (or would that work)? Thanks, Anthony > Jung-uk Kim > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"= From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 17 07:05:01 2015 Return-Path: Delivered-To: freebsd-acpi@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id EF4A66F9 for ; Tue, 17 Mar 2015 07:05:01 +0000 (UTC) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id D4172B70 for ; Tue, 17 Mar 2015 07:05:01 +0000 (UTC) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.14.9/8.14.9) with ESMTP id t2H751kY003327 for ; Tue, 17 Mar 2015 07:05:01 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-acpi@FreeBSD.org Subject: [Bug 198603] [acpi] HP ProBook 430 G2: can't change brightness via acpi_hp and acpi_video Date: Tue, 17 Mar 2015 07:05:01 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.1-STABLE X-Bugzilla-Keywords: X-Bugzilla-Severity: Affects Many People X-Bugzilla-Who: xnasx@yandex.ru X-Bugzilla-Status: New X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-acpi@FreeBSD.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 07:05:02 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=198603 --- Comment #1 from Victor Yagofarov --- I solved my problem by compiling intel_backlight like that : https://forums.freebsd.org/threads/samsung-ativ-book-2-brightness.44146/#post-249316 -- You are receiving this mail because: You are the assignee for the bug. From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 17 12:28:31 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id CDD34DE3; Tue, 17 Mar 2015 12:28:31 +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 19CA27CF; Tue, 17 Mar 2015 12:28:30 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2HCSLMS023814; Tue, 17 Mar 2015 23:28:21 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Tue, 17 Mar 2015 23:28:21 +1100 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: [PATCH] ACPI CMOS region support rev. 5 In-Reply-To: <55073442.5060005@att.net> Message-ID: <20150317222704.K22641@sola.nimnet.asn.au> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; CHARSET=US-ASCII Content-ID: <20150317222704.G22641@sola.nimnet.asn.au> Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 12:28:31 -0000 On Mon, 16 Mar 2015 15:51:30 -0400, Anthony Jenkins wrote: > On 03/16/2015 01:49 PM, Ian Smith wrote: > > On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote: > > > On 03/16/2015 11:00 AM, Anthony Jenkins wrote: > > > > On 03/16/2015 09:59 AM, Ian Smith wrote: > > > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > > > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) > > > >>> + return AE_BAD_PARAMETER; > > > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 > > > >> bytes - or pass it 'bytes' also, and loop over each of them within? > > > >> ======= > > > >> > > > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from > > > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write > > > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). > > > > Right, this is an (incorrect) hybrid of a few attempts, probably from > > > > around the time I lost my SSD and only had a single backup copy of my > > > > work to go from. In one revision I had disallowed all multibyte > > > > accesses (width > 8) since IMHO it was more consistent/correct with the > > > > suggested locking. I wasn't ignoring your suggestion, just making one > > > > or a few changes at a time (generally the simpler ones). > > > > > > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS > > > does a multibyte op on a set of bytes whose last byte fails > > > acpi_check_rtc_byteaccess(). I will have already performed n-1 > > > accesses. At one point I had a revision (acpi_check_rtc_access()?) that > > > permitted/denied the entire request (it took the starting address and > > > byte length), but I guess that got lost too. I'll just recreate it... > > > > Yep, validating all access before doing any sounds like the way to go. > > > > Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07), > > so non-multiples of 8 bits are invalidated anyway. You should still > > check that width (or bytes) > 0, even if 0 should never be passed. > > Oh yeah, forgot about that! > > > I guess the Big Kids will start playing once this hits bugzilla? :) > > I'm just glad I get to learn how to commit stuff to FreeBSD. > > Here's another iteration...comments welcome. Think I got (most) > everything in there. I need to unit test acpi_check_rtc_access() to > make sure it DTRT? You've fixed all my concerns, thanks Anthony. A couple of questions: +#ifndef ATRTC_VERBOSE +#define ATRTC_VERBOSE 1 +#endif Where else might ATRTC_VERBOSE be set otherwise? +static unsigned int atrtc_verbose = ATRTC_VERBOSE; +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); +#define ATRTC_DBG_PRINTF(level, format, ...) \ + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) Genuine question, I don't know .. but would not that 0 in SYSCTL_UINT initialise atrtc_verbose to 0? Or does it keep its existing setting? Or would replacing 0 there with ATRTC_VERBOSE work, or be clearer? static int +acpi_check_rtc_access(int is_read, u_long addr, u_long len) +{ + int retval = 1; /* Success */ + + if (is_read) { + /* Reading 0x0C will muck with interrupts */ + if (addr + len - 1 >= 0x0C && addr <= 0x0c) + retval = 0; Looks alright to me, given my uncertainty with C operator precedence. + } else { + /* Allow single-byte writes to alarm registers and + * addr >= 0x30, else deny. + */ + if (!((len == 1 && (addr <= 5 && (addr & 1))) || addr >= 0x30)) + retval = 0; + } + return retval; +} After a short struggle unwinding brackets, this looks right; but I will suggest clarifying the comment: + /* Allow single-byte writes to alarm registers and - + * addr >= 0x30, else deny. + + * multi-byte writes to addr >= 0x30, else deny. I still wonder if there isn't a global acpi_loaded_and_running variable so you could avoid even attempting ACPI init calls, perhaps making this not so dependent on ACPI, at least at runtime. But perhaps jkim's concern is more regarding building on platforms not supporting ACPI at all? Is that the (only?) issue with this on ARM? cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Tue Mar 17 13:05:23 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 8A683651 for ; Tue, 17 Mar 2015 13:05:23 +0000 (UTC) Received: from nm21-vm6.bullet.mail.ne1.yahoo.com (nm21-vm6.bullet.mail.ne1.yahoo.com [98.138.91.114]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4B673BB2 for ; Tue, 17 Mar 2015 13:05:22 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426597345; bh=dJY2WFve6K/KC8xYUFd1Lhhn9pXd9szUncS9vKZLcGk=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=jOk+3bTEYWdQCj4LCOASPaKWx3XTobWur9emALa0y3NkJ9shohXPZfwb2XgCDZTydLa3KaFmm4Rf7iiXvZnGcpSX6r6bAnhqvNpzTAn5Qnd8yiKESlNHDl2t7N1Zw0fELCVMI0HQ97jBbywy144RSjNjhZd4m5u7SX8F7NSF2VI= Received: from [98.138.226.177] by nm21.bullet.mail.ne1.yahoo.com with NNFMP; 17 Mar 2015 13:02:25 -0000 Received: from [98.138.84.44] by tm12.bullet.mail.ne1.yahoo.com with NNFMP; 17 Mar 2015 13:02:25 -0000 Received: from [127.0.0.1] by smtp112.mail.ne1.yahoo.com with NNFMP; 17 Mar 2015 13:02:24 -0000 X-Yahoo-Newman-Id: 993104.4951.bm@smtp112.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: Wi5eXLYVM1k.SMw_8q0FRChh7kwHzQDCPlecVpQOSx7yBDS UleQfnLf6_G3DLetTMmFaFMUedLj1S6po4ag7IHIW3IXfGIgCPxPxpT6Y8yJ C95BNJXSDoAtqXuknktP3JMgMNsND6dRv8XYKgaJ2p5p5Pu0rBb9.QAokJwP M3TzStihail.IYDyZ3x.dpK65P1u9J7sbNMvZhPLzCoBr8mSleeFVYcd1ApD lS9tYHUJV4qkhJztfwqD6Yvgdfjhu2eo1ZLVS6HdV7CwE53eLzy6DR8hYwnG 6b0bAfpdNhdu0N0A4Ro9v07ioYxbK8TJmzXlnEJNnlItNDOVpmpHxN.msSyf 4Ap_AA7Svu2pBXZY4R2MXTpOo5R17Nl41akms7wvpUavoTL.uekgdMWLvwdU 91SdGYOcT8qZqlB8SuPuXmA_PLEueyAb3W_B57oSTMJlqsNwy7oFldzQkzb9 Ceid4gRKbtxviz6Xrjmzc_j_zA8wTeZs_TwQ7AWGxE2LKHjasfznct4_Lp43 rbLo.MkDkoVODyE31nYCPTLOGxB_ob9gV5LZ3q6PXl8cLdXnP X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <550825DE.7030406@att.net> Date: Tue, 17 Mar 2015 09:02:22 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> In-Reply-To: <20150317222704.K22641@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 17 Mar 2015 13:05:23 -0000 On 03/17/2015 08:28 AM, Ian Smith wrote: > On Mon, 16 Mar 2015 15:51:30 -0400, Anthony Jenkins wrote: > > On 03/16/2015 01:49 PM, Ian Smith wrote: > > > On Mon, 16 Mar 2015 11:50:59 -0400, Anthony Jenkins wrote: > > > > On 03/16/2015 11:00 AM, Anthony Jenkins wrote: > > > > > On 03/16/2015 09:59 AM, Ian Smith wrote: > > > > >> On Sat, 14 Mar 2015 23:40:34 -0400, Anthony Jenkins wrote: > > > > >>> + if (!acpi_check_rtc_byteaccess(function == ACPI_READ, address)) > > > > >>> + return AE_BAD_PARAMETER; > > > > >> acpi_check_rtc_byteaccess() needs to be called per byte of 1, 2 or 4 > > > > >> bytes - or pass it 'bytes' also, and loop over each of them within? > > > > >> ======= > > > > >> > > > > >> Otherwise (for example) a 2 byte read from 0x0b or 4 byte read from > > > > >> 0x09-0x0b will read 0x0c (clearing interrupts), or a 2 or 4 byte write > > > > >> to (say) 0x01 will also write to 0x02 and 0x04 (clobbering the time). > > > > > Right, this is an (incorrect) hybrid of a few attempts, probably from > > > > > around the time I lost my SSD and only had a single backup copy of my > > > > > work to go from. In one revision I had disallowed all multibyte > > > > > accesses (width > 8) since IMHO it was more consistent/correct with the > > > > > suggested locking. I wasn't ignoring your suggestion, just making one > > > > > or a few changes at a time (generally the simpler ones). > > > > > > > > Okay now I remember why I was reluctant to do this - suppose ACPIBIOS > > > > does a multibyte op on a set of bytes whose last byte fails > > > > acpi_check_rtc_byteaccess(). I will have already performed n-1 > > > > accesses. At one point I had a revision (acpi_check_rtc_access()?) that > > > > permitted/denied the entire request (it took the starting address and > > > > byte length), but I guess that got lost too. I'll just recreate it... > > > > > > Yep, validating all access before doing any sounds like the way to go. > > > > > > Also, bytes = width >> 3 is ok, since you then affirm !(width & 0x07), > > > so non-multiples of 8 bits are invalidated anyway. You should still > > > check that width (or bytes) > 0, even if 0 should never be passed. > > > > Oh yeah, forgot about that! > > > > > I guess the Big Kids will start playing once this hits bugzilla? :) > > > > I'm just glad I get to learn how to commit stuff to FreeBSD. > > > > Here's another iteration...comments welcome. Think I got (most) > > everything in there. I need to unit test acpi_check_rtc_access() to > > make sure it DTRT? > > You've fixed all my concerns, thanks Anthony. A couple of questions: > > +#ifndef ATRTC_VERBOSE > +#define ATRTC_VERBOSE 1 > +#endif > > Where else might ATRTC_VERBOSE be set otherwise? I'm picturing a (future?) config(5) knob, e.g. device atrtc options ATRTC_VERBOSE=1 so it can be set at compile time. > +static unsigned int atrtc_verbose = ATRTC_VERBOSE; > +SYSCTL_UINT(_debug, OID_AUTO, atrtc_verbose, CTLFLAG_RWTUN, > + &atrtc_verbose, 0, "AT-RTC Debug Level (0-2)"); > +#define ATRTC_DBG_PRINTF(level, format, ...) \ > + if (atrtc_verbose >= level) printf(format, ##__VA_ARGS__) > > Genuine question, I don't know .. but would not that 0 in SYSCTL_UINT > initialise atrtc_verbose to 0? Or does it keep its existing setting? > Or would replacing 0 there with ATRTC_VERBOSE work, or be clearer? Ahh, good catch... guess I don't even need the variable initializer. > static int > +acpi_check_rtc_access(int is_read, u_long addr, u_long len) > +{ > + int retval = 1; /* Success */ > + > + if (is_read) { > + /* Reading 0x0C will muck with interrupts */ > + if (addr + len - 1 >= 0x0C && addr <= 0x0c) > + retval = 0; > > Looks alright to me, given my uncertainty with C operator precedence. > > + } else { > + /* Allow single-byte writes to alarm registers and > + * addr >= 0x30, else deny. > + */ > + if (!((len == 1 && (addr <= 5 && (addr & 1))) || addr >= 0x30)) > + retval = 0; > + } > + return retval; > +} > > After a short struggle unwinding brackets, this looks right; but I will > suggest clarifying the comment: > > + /* Allow single-byte writes to alarm registers and > - + * addr >= 0x30, else deny. > + + * multi-byte writes to addr >= 0x30, else deny. Okay. > > I still wonder if there isn't a global acpi_loaded_and_running variable > so you could avoid even attempting ACPI init calls, perhaps making this > not so dependent on ACPI, at least at runtime. I haven't (yet) been able to find a compile-time flag that tells me if the kernel supports ACPI; I'm /pretty/ sure the ACPI headers I'm #include'ing will exist for every build of FreeBSD. > But perhaps jkim's concern is more regarding building on platforms not > supporting ACPI at all? Is that the (only?) issue with this on ARM? Ehh... I'll wait for him to chime in. I could try cross-compiling the kernel for an ARM box, but I doubt sys/x86/isa/atrtc.c is even picked up by those. Thanks, Anthony > cheers, Ian > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org" From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 15:27:02 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A44D84F7 for ; Wed, 18 Mar 2015 15:27:02 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 61F9BB64 for ; Wed, 18 Mar 2015 15:27:01 +0000 (UTC) Received: by igcqo1 with SMTP id qo1so47237495igc.0 for ; Wed, 18 Mar 2015 08:27:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=n02PobBQKq7HNZDdWPFT2DbwxN+ZPZ7NalQz/asWOx8=; b=HK9GBlThrPLd4f1n1yd6p9zc7JTjxiVcomNJM0w62syU9bIpPgOKgIllJbu7RdpeZv mAEsQKKM/ZnTMtOnSBR1EPyeTZztF2Z9JObE1MEVxEe4S6RqCCjeRNpBClkJhbm0/bxg f/8lFuZdhRXjLCSx+8ixIElnBjg5Astx/4Lnt2SRYVVTQm1ETHWKlVmQd+mLRjjbDtZl MJhTFOBUhLgXwYLTg6LMCkS+K7OFRHTBHR7bfJqS3pu8S+yxzD+0/WXnEF5/NueTl5xt 6SnJEv2nD2wC8UTUbq8etbmKBLxw1kqMNEkpn/i6hQBpGlSRp1atmDHLZVhVzV1/rYFY AxBQ== X-Gm-Message-State: ALoCoQl6EslPq6cn2wxwmmHUm/X5ZfWDnVJjS34/2F4r+ZnZw/MVKXXu/cbNR9Y9kyHBZNf1Eply X-Received: by 10.42.109.12 with SMTP id j12mr94985622icp.22.1426692420932; Wed, 18 Mar 2015 08:27:00 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id b1sm1900338igl.7.2015.03.18.08.26.59 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 08:26:59 -0700 (PDT) Sender: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_D7979BF8-79E7-4CBE-8EA4-61A4A313E38A"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: <55073442.5060005@att.net> Date: Wed, 18 Mar 2015 09:26:57 -0600 Message-Id: References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> To: Anthony Jenkins X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:27:02 -0000 --Apple-Mail=_D7979BF8-79E7-4CBE-8EA4-61A4A313E38A Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 Looking at patch 5: You need to rework this so there=92s an atrtc_acpi.c. Put all the ACPI = attachment in there. You should also split off the little bit that=92s = ISA-specific into atrtc_isa. Once you do that, we can talk. Warner --Apple-Mail=_D7979BF8-79E7-4CBE-8EA4-61A4A313E38A Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCZlCAAoJEGwc0Sh9sBEAnNkQAMxPy3zipMjBkgJyD7TgIciI iODg5RlQpHdfvvyAaruMKENOhSVUCf0oM/uXxrcLitkew1w+PFaeYwIZH2G1HlK1 wa4VQky/e7LvB0jZ7jUaCEFdujBd1SQ7+ey7lseBOVPq3nXtIx/aXL1lQNethohe s+S55hxBhPh5zHIEmcjYD/nXiPWTvT6zganF4LvdVEdhUzeOX1I40LmRmHNK0L/K DCQkuytG2Zu6+yYLO7+TjFBkG3YDrUUiQ7Q7R+8vKHEhSj6J7HVQpxo836qbTiXa 4VffDqEZwnpr3TCE7g+oTwF/u2R5hikj8EnoIqIWWZQCsIzmhpWCQrEwHmpMYN/3 xvQGUlKLjOPgv8y5k7C9mAmNaD45xFsr4CkWQO8jrFhFr2E647ZOMZY8mSde78U+ 18kOgjwfBaDk3JkkUz+87WySnt59lZfxrHNEGlP1CQycx4mCr6jUH5ULpgFUwB7c CicN+BCmPiQUgepDt+/lWsYMsF9xJnO7f4HjErNdmxxiBYfNwnnRQa7Mg5/oXyXv Q2cUkNK2xy8ZqWMP043od6ZoFpRx4gokD8/AgLFmpsBIdA81Kw2bE4+XGJmdj/Qg NJ4pjptjndskuGKYouDulK4VS1G+Xna2mqLEToGG+E2qjC+zMT5P11Pa09ZEjjvq F6TaT+2DKuuy3PhoZahJ =e43x -----END PGP SIGNATURE----- --Apple-Mail=_D7979BF8-79E7-4CBE-8EA4-61A4A313E38A-- From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 15:29:50 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 383AF736 for ; Wed, 18 Mar 2015 15:29:50 +0000 (UTC) Received: from mail-ig0-f176.google.com (mail-ig0-f176.google.com [209.85.213.176]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id E9447B98 for ; Wed, 18 Mar 2015 15:29:49 +0000 (UTC) Received: by igbue6 with SMTP id ue6so47397940igb.1 for ; Wed, 18 Mar 2015 08:29:43 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=9JNI7Qv9suo3aMLwLwVxD2wDRqlc7GD9FgrhBscdiY8=; b=KSoTQDxlcxriJNb1GLQ5UVnOx9hol5Z+wMsGtprcjF3N0rGjhaLTo2YmjKeRMZUTSq uRFfPGCTf0Os7H9NlyWFsJWAz1bp5Ee0fm2wWVlJsT4R2q2BKszbo0+M3LLRwUcYizUn 4NCT3QZtg7Ywb2XW2H5sN423QdIwa4sbbgCt3j8z7bGFwJHfv8sADY9hNJK8hFGFy7xb kJCV2TCxsQ19VJIaGZBxAwXlcK0tr6EKPmT+tbZgZccFn5w6jvIK8On/OcZg6JeDEkfh c2x1GAapAm5SszAhrCko7ze0vSUwDG8A+AF16F4b0R48isHRPvizgGWYSwNJqMcTaQGX hDOQ== X-Gm-Message-State: ALoCoQlmg0HYyMbs9VKCINp5/qZkqdpDQKI83Zd0WF8JAvP2ZyGyyUAQNEx9eZomZXmmtF46AWWN X-Received: by 10.42.47.8 with SMTP id m8mr93317177icf.27.1426692583413; Wed, 18 Mar 2015 08:29:43 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id c76sm11099850ioc.16.2015.03.18.08.29.42 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 08:29:42 -0700 (PDT) Sender: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_E8AB9B17-59A9-468A-9351-9347B12813F1"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: <550825DE.7030406@att.net> Date: Wed, 18 Mar 2015 09:29:41 -0600 Message-Id: <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> To: Anthony Jenkins X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:29:50 -0000 --Apple-Mail=_E8AB9B17-59A9-468A-9351-9347B12813F1 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 17, 2015, at 7:02 AM, Anthony Jenkins = wrote: >> \Where else might ATRTC_VERBOSE be set otherwise? >=20 > I'm picturing a (future?) config(5) knob, e.g. >=20 > device atrtc > options ATRTC_VERBOSE=3D1 >=20 >=20 > so it can be set at compile time. Why not just boot verbose? history has shown too many options like this is hard to use. >> I still wonder if there isn't a global acpi_loaded_and_running = variable >> so you could avoid even attempting ACPI init calls, perhaps making = this >> not so dependent on ACPI, at least at runtime. >=20 > I haven't (yet) been able to find a compile-time flag that tells me if > the kernel supports ACPI; I'm /pretty/ sure the ACPI headers I'm > #include'ing will exist for every build of FreeBSD. I wouldn=E2=80=99t count on it. However, they may exist for all = platforms that use atrtc. But it wouldn=E2=80=99t be an issue if you did a separate attachment. Warner --Apple-Mail=_E8AB9B17-59A9-468A-9351-9347B12813F1 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCZnlAAoJEGwc0Sh9sBEAm7IQANRXjySCQtWnYjJ1MkvIY5zo Wkvs8Sj4dQEX9PTcAUPywJVSij94JY9EDzP0XLBVat/LYk84g6zdM3eT/+nsJsoQ OGw4jsi45dJma7akdTFFlVgHWFP1WYbxaBBq/eEW8RPrmv9BRir8yrrf2vF2Iqzu u4LeTeJwciFvIoQIw9kP4n9GRI/8/4wxILazgSX868Xf05wIukP3WsPCBijb/94T b6OT33o9lqMm8ip3h3gaH19SouatBYFE3vsWQsdP994N5+rgHjukaVehQYQwDQHK jLjRjXPUzs49LyHq68Y8zGxHm1G4sZ9VT7ZxNTfbPeXJmByb41UUF6ZhOQ/hCOPC AldL1DSZVOngEKXpp26jPoNYZAyXWE85Fat+wjOSlS+dUxAKeLFlqtNNsCVBlrvj ++7UroKpbGP29jEVAGVGmYZ0Z6wyFt+XKbAe/4rJByzL78181m4lDKaEBvkQu0Bz gpCuw2zhoql+BrCnqB1elj0TfEeuG358TZB/BDCiN3Yhwf9ahlF2mXNfCoCIR+ab CfUXuS8V/eaPmZ+s4w1SxigYf4cHXrK/JlV8UDjQkltuHWogQfBTGJmw23JNR0JN aJWo5KwV08ZTX6tzghCqUr5PaToKty4twHJNyly1fEjkInb4A2XbxIwTCaECihmx IepINYnPbHOoGsq6MUL/ =ciL6 -----END PGP SIGNATURE----- --Apple-Mail=_E8AB9B17-59A9-468A-9351-9347B12813F1-- From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 15:59:47 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 08134DA5 for ; Wed, 18 Mar 2015 15:59:47 +0000 (UTC) Received: from nm19-vm4.bullet.mail.ne1.yahoo.com (nm19-vm4.bullet.mail.ne1.yahoo.com [98.138.91.179]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id B5626ECD for ; Wed, 18 Mar 2015 15:59:46 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426694380; bh=G63wEoQhnDhv9zhDMI92RY9uNlKMxMJ2E7pNuqpvyqY=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=oL40Me+3BSZwmn7qAVBc8XSozRs3iDIzkM0g315037blf94BcWQqE5qx/yIcSu54niQoxpjsEYIi83g1LDzBQlgT2bI8wpBLeurx+5z5N+gpWWCa4UnSM9ZrH1IXCrwNPBps82wpcXTXMDgGQ7nxCMgBHEzogQYROz7KHqgvkfg= Received: from [98.138.100.117] by nm19.bullet.mail.ne1.yahoo.com with NNFMP; 18 Mar 2015 15:59:40 -0000 Received: from [98.138.84.45] by tm108.bullet.mail.ne1.yahoo.com with NNFMP; 18 Mar 2015 15:59:39 -0000 Received: from [127.0.0.1] by smtp113.mail.ne1.yahoo.com with NNFMP; 18 Mar 2015 15:59:39 -0000 X-Yahoo-Newman-Id: 984224.81593.bm@smtp113.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: NNqKkvAVM1lXHeLOKPsDIesHI0zVwfiwNPIBsMkB0sb9f0H PRsxPtMmwUC.YBSClN2fre.pucVgfzTYyJvMX50FTE9ecVtP7n8bbgFDIyl7 3JePJhvn3Cr.UiGe0DzpgutBNtv5ZqPPfShWAAolzsK2AXh.mszioNk2M24t Rq.oNgunA3.m8owvbMjtl_EiKKMrzkuphYUdvDbpcdfWb2l_qqVjHH1dk6xN iSyCrf4fjXMNf656Oh1VEZ9E9rf4wsVc0ViJKOX9_E3kuHPEERqq7neIM0W2 hjfTSP0bDx69pxczbstfckUvfj2VGd1x5AXtQBMtymezHr6RWYqs2L4UkkPQ i1MtOun.RT7qzbIs4sN1gvlB__2VNa9g3fTdHdDQeND5nS1jqZbLkhp03B73 30Vy0ekqkojTSeYo1VnWlJYECQXZOR_roi97keFFGKLWTKFVj2yJ6MR84lcv 5klnzN_dq6Hggp6gnUQV5moPgOd3nGTKqr_kQZH4Dp2YV2.8yz9xlI4_5.Ng ugVLLI23r3i8n1nfOiQV_vTCqmNnQnzHcp0ioeGXd6Chjqlhn X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <5509A0EA.4070208@att.net> Date: Wed, 18 Mar 2015 11:59:38 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:59:47 -0000 On 03/18/2015 11:26 AM, Warner Losh wrote: > Looking at patch 5: > > You need to rework this so there’s an atrtc_acpi.c. Put all the ACPI attachment in there. Okay, shouldn't be a problem. > You should also split off the little bit that’s ISA-specific into atrtc_isa. You mean rtcin() and writertc()? ...but that's not my stuff, it was already in atrtc.c. PNP0800 (the PC-AT RTC component) is (practically) an ISA-specific device. Anthony > Once you do that, we can talk. > > Warner > From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 16:06:34 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1397C2FC for ; Wed, 18 Mar 2015 16:06:34 +0000 (UTC) Received: from nm10-vm5.bullet.mail.ne1.yahoo.com (nm10-vm5.bullet.mail.ne1.yahoo.com [98.138.91.232]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id BF018FCE for ; Wed, 18 Mar 2015 16:06:33 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426694787; bh=6zbn+LjDN4B+UQt52p7dnVa37HG30NXfLJkfY11cyV0=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=Yb/8GeIsVbMrYIFWOtt1pcymQtUgX24p0+8jd4SeogI8s0fbmJQlP9+QjZ8Om2jERlSrMAWQJ1ZeTovO9mDwOJO4varNvSMNCsBXkg3IhLyKQlH/kxSVrqzNfSJseROiUFkcRWbBzQ6gpfdEz3fTEqqVnj+pPdsT9z9gN/eaz9k= Received: from [98.138.101.132] by nm10.bullet.mail.ne1.yahoo.com with NNFMP; 18 Mar 2015 16:06:27 -0000 Received: from [98.138.84.46] by tm20.bullet.mail.ne1.yahoo.com with NNFMP; 18 Mar 2015 16:06:27 -0000 Received: from [127.0.0.1] by smtp114.mail.ne1.yahoo.com with NNFMP; 18 Mar 2015 16:06:27 -0000 X-Yahoo-Newman-Id: 465972.16561.bm@smtp114.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: 2ByjoawVM1kCqu10Q51ls53YmVh8Qah70OAeq3X84k6E993 P1e.NQYYy7Faat6pDB0eHZqenhBwK2dIa3Q8IhrTVCixapBFDmlCAUgQ1eG9 iWhhE2choCMMRtXIH8hPdN9hJgViAas.aGbVjbd018wIVmWCeplFehybazyo .PTPTWKUhaYXJCxxScmDw470mQcdQ6_B.xqeD_msw5gkVW9FnymIj77KvvnH col1y33iYgptl1N2e0madi_Xof1s4onaJqsamyNmyYXftwKX88uRBmocqSFt hQ3LGgQ_W4m9Q7koLKNG9.rO12QZ8dBiOE.sQ.WwGWT29qBpONLIaebZsZC8 VptCL92YOzcgCb42265Rm5cwsMeft24L.sc1kFViRCs3iMZS0TWkTBFMdpaz V8ES91sojsZyw46ZDQhUggQItrpkvoTS3IKxxGZ62P3.THmBxcj0XVfMZcc2 S0m_xUA7wfJDp3mTDQQekt8JvkdFyZ6hkw_rK411RZqJryW8tdcMmDVsBtUM kcO4eqZgzmZqN.sES2zYJGMgOj16bj0UvxAomlDETiiu34iUc X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <5509A282.6070207@att.net> Date: Wed, 18 Mar 2015 12:06:26 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> In-Reply-To: <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 16:06:34 -0000 On 03/18/2015 11:29 AM, Warner Losh wrote: >> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins wrote: >>> \Where else might ATRTC_VERBOSE be set otherwise? >> I'm picturing a (future?) config(5) knob, e.g. >> >> device atrtc >> options ATRTC_VERBOSE=1 >> >> >> so it can be set at compile time. > Why not just boot verbose? history has shown too many options like > this is hard to use. I think I understand what you're saying... I also prefer fewer config(5) knobs. So you're suggesting I determine (at runtime) the boot verbose setting (kenv(2) or however it's properly done) and dump the compile-time verbosity setting? Thanks, Anthony >>> I still wonder if there isn't a global acpi_loaded_and_running variable >>> so you could avoid even attempting ACPI init calls, perhaps making this >>> not so dependent on ACPI, at least at runtime. >> I haven't (yet) been able to find a compile-time flag that tells me if >> the kernel supports ACPI; I'm /pretty/ sure the ACPI headers I'm >> #include'ing will exist for every build of FreeBSD. > I wouldn’t count on it. However, they may exist for all platforms that > use atrtc. > > But it wouldn’t be an issue if you did a separate attachment. > > Warner > From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 17:35:24 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx2.freebsd.org (mx2.freebsd.org [8.8.178.116]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 404B895B for ; Wed, 18 Mar 2015 17:35:24 +0000 (UTC) Received: from hammer.pct.niksun.com (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx2.freebsd.org (Postfix) with ESMTP id DF6DB1D82; Wed, 18 Mar 2015 17:35:23 +0000 (UTC) Message-ID: <5509B75B.3070409@FreeBSD.org> Date: Wed, 18 Mar 2015 13:35:23 -0400 From: Jung-uk Kim User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith , Anthony Jenkins Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> In-Reply-To: <20150317222704.K22641@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 17:35:24 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 03/17/2015 08:28, Ian Smith wrote: > I still wonder if there isn't a global acpi_loaded_and_running > variable so you could avoid even attempting ACPI init calls, > perhaps making this not so dependent on ACPI, at least at runtime. For runtime, power_pm_get_type() is what you looking for. For example, switch (power_pm_get_type()) { case POWER_PM_TYPE_ACPI: /* Do something specific to ACPI. */ case POWER_PM_TYPE_APM: /* Do something specific to APM. */ default: /* Do something without PM. */ } > But perhaps jkim's concern is more regarding building on platforms > not supporting ACPI at all? Is that the (only?) issue with this on > ARM? sys/x86/isa/atrtc.c is only for x86 (excluding pc98). I am only concerned about ACPI-less i386 kernel at this point. Jung-uk Kim -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVCbdVAAoJEHyflib82/FGK04H/2e/DVefzoorkEuW5sxgHqGg XGFB21wLxP4bfnkkGlTfYrEPkdB53zW6qez2nUv+zA4aTy/BTpmRN0KAhwMRCkJj QjM757IoQr+QyWQhU62NOsu7Ox86MI6RBrPssURuwib8HWJbIUPDKKYmK+sXI7Bq UmlBJeiK0BhzCQ7l0tIaR6VFlQSxMQC/x/fwkHI9hKPyKwq8ACeqQ2ZI05v6ZQzo IIfVU0LLz62kDoJDicaRNfJbGtRPOvx4Nnm1RE8wVtaqlwQYrffp6QpHaRfXHEos QwWEWXrMFfjQtCH+KCrzfZsCQD1rTe+eDb0tFD315PbpvEs6yG6VlBxf4pUJRAU= =YDkP -----END PGP SIGNATURE----- From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 21:30:32 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 4A977D3E for ; Wed, 18 Mar 2015 21:30:32 +0000 (UTC) Received: from mail-ie0-f172.google.com (mail-ie0-f172.google.com [209.85.223.172]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 05A75DDD for ; Wed, 18 Mar 2015 21:30:31 +0000 (UTC) Received: by ieclw3 with SMTP id lw3so50330593iec.2 for ; Wed, 18 Mar 2015 14:30:25 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=az5AoubzhereylYekwZf9o7fmZ/z5sXTBtxcUd4ipvE=; b=jcfp85Z1eLR3nFS0XQRCXpPWGSW10aXj/DuHbMNgpYhDIfaX64nqrr1rDAY1ZnwxAM 3ig9qfceQ/hdD6ypeIn/NKOEHjapOUKgBMAUnLNpHx71WX9fsHaehHuxdfLVRhc6Xiz/ 5ij7L3absExNnky0mlfToE43lXrypG6KPvZSU0PEaUE7uf4u85mZQr1ESWSB+NiVSDT1 xyjsTX3grJQ+oZrMn8p8vd3ZHHPvBv8cM25bmjhA8NiDKTwglYrk4SdwGD2wEPbH41D3 6cTByqU0UGvkCzqK3xITrS+bPhbVoPfMwgBONLqFFiCVJ2yND/uEDHfSjLIjsfyX3yMY Y/qw== X-Gm-Message-State: ALoCoQl+DAWycPgzo/LPmMrco2M1OptjNE1k8uq71G00OgeWyEbuRHl1ZGxqjLZbt95aBXce4db9 X-Received: by 10.42.0.9 with SMTP id 9mr2915074ica.49.1426714225299; Wed, 18 Mar 2015 14:30:25 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id l197sm11778005iol.1.2015.03.18.14.30.24 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 14:30:24 -0700 (PDT) Sender: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_8F5DFFC0-12FC-4445-A884-6E9D58905CE6"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: <5509A282.6070207@att.net> Date: Wed, 18 Mar 2015 15:30:23 -0600 Message-Id: References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> To: Anthony Jenkins X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 21:30:32 -0000 --Apple-Mail=_8F5DFFC0-12FC-4445-A884-6E9D58905CE6 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins = wrote: >=20 > On 03/18/2015 11:29 AM, Warner Losh wrote: >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins = wrote: >>>> \Where else might ATRTC_VERBOSE be set otherwise? >>> I'm picturing a (future?) config(5) knob, e.g. >>>=20 >>> device atrtc >>> options ATRTC_VERBOSE=3D1 >>>=20 >>>=20 >>> so it can be set at compile time. >> Why not just boot verbose? history has shown too many options like >> this is hard to use. >=20 > I think I understand what you're saying... I also prefer fewer = config(5) > knobs. So you're suggesting I determine (at runtime) the boot verbose > setting (kenv(2) or however it's properly done) and dump the > compile-time verbosity setting? if (bootverbose) do verbose things; is how that=E2=80=99s done. Warner --Apple-Mail=_8F5DFFC0-12FC-4445-A884-6E9D58905CE6 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCe5vAAoJEGwc0Sh9sBEAPjYP/RBSWMaMqV6qqi442nPe1jQy TlCpeisbRV60sDGrZUrXola7XBiQLhuabX3vAwCXFrG6fgYKmbIPYyQ91KJMtMBw AZUSnr8kJADeo+bdXiMtVisdit2tHnM+ARObdy0NRBZb6kw6louttgOmicO66Nxm 7ZBnYaOAEHdufAdiM7B0MRnU9mXQsfg6o/5wxDizu56spfbAJcrlDEsk0zcpPFWg ttad0dRq+EJaOalG6Iu4+i+TKKna003LwCVZNwEcK3/KvLGlHjW+po3gKSeHQM++ kxmVEz+U2dVQUBFsJ2qqbqlpXEaLoW2oKYv3I72Mtc34c5jUcQLUxNtLHVIV4xWI 7m3LdJ2f1BBtu11oYubKB1JM1XL6jKsmnMqJYniKLZ1QEL/iucVp63V1FI7Mxs6R znxTa7+1NexqDD09R0+ROh7HOj9o4I6uwZGji6n71VbeSiOJD9KApznO28yTAkHB Q45CQq8ueZYirXXLsY6NWKTOXDFcOc3andF3iSKidBrdGJJ8tXr01Mv5W7/xiMPF 43TVHXZxcGNLbUbml3LzROvwq82WRIvhPHrTY2wKUBpuKa5XIbZd3fOvRlqLzB1o 9oQqCAItJSuauPvpaOy2RLhOCgf20w/zmvDpV7YnbPEfKOg5WWK4pHbSKKMJjikQ 9u96vhg/L+c3p6MSLPHP =V7IN -----END PGP SIGNATURE----- --Apple-Mail=_8F5DFFC0-12FC-4445-A884-6E9D58905CE6-- From owner-freebsd-acpi@FreeBSD.ORG Wed Mar 18 21:32:16 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id ED9F2D99 for ; Wed, 18 Mar 2015 21:32:15 +0000 (UTC) Received: from mail-ig0-f173.google.com (mail-ig0-f173.google.com [209.85.213.173]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A9A9CE7B for ; Wed, 18 Mar 2015 21:32:15 +0000 (UTC) Received: by igbud6 with SMTP id ud6so6086240igb.1 for ; Wed, 18 Mar 2015 14:32:09 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:subject:mime-version:content-type:from :in-reply-to:date:cc:message-id:references:to; bh=b9si3uO6fvm63wwsRGau93/CfAGeb7g/tdkM/utXHTg=; b=kJJX75ELqQnUjugSy4fws/9yDcx5iXmRDCzhx6KUolQnAXSrv5MsVfHdDOuGBUiRbp aetChzNtjXUSOG+vE0vfk3q61p3gIFqyLfK/d+CKVm5jYNQwqgKFUlmmrgCW2v9Zct70 UIxCmz7jS6DIAADyvcRQCFwvVYWeG0+CVuQj9AQltXW0OoC9+2oFzA0nb/sXspItnEPv 02SMoUdxu3rD/wqYi4TWOcjIiAlLtlau9ge5GzGZ4Jx3bP6SYNIFPf7xVcUeUptOF3sH Rslt/2i13dV4ratBWX/RU3Q38MyXpI7EJXvc7Kk7LJMJovToL8nd6jFO1nu8W7KpuFJ4 8enQ== X-Gm-Message-State: ALoCoQk4jWrICy45mFkzshasRhlSApgsrl/hgER6vqZxsQzHUR6ySFlNFLYkbqXw9BxyTTjPXSyj X-Received: by 10.42.236.79 with SMTP id kj15mr7767590icb.40.1426714329527; Wed, 18 Mar 2015 14:32:09 -0700 (PDT) Received: from netflix-mac.bsdimp.com ([50.253.99.174]) by mx.google.com with ESMTPSA id o8sm2571722igp.11.2015.03.18.14.32.08 (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 18 Mar 2015 14:32:09 -0700 (PDT) Sender: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\)) Content-Type: multipart/signed; boundary="Apple-Mail=_A9D859D8-4CD7-4618-9C77-32F238BE7026"; protocol="application/pgp-signature"; micalg=pgp-sha512 X-Pgp-Agent: GPGMail 2.5b5 From: Warner Losh In-Reply-To: <5509A0EA.4070208@att.net> Date: Wed, 18 Mar 2015 15:32:08 -0600 Message-Id: <85F2CFD2-14C1-43D6-8963-0D1F69F17577@bsdimp.com> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <5509A0EA.4070208@att.net> To: Anthony Jenkins X-Mailer: Apple Mail (2.2070.6) Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 21:32:16 -0000 --Apple-Mail=_A9D859D8-4CD7-4618-9C77-32F238BE7026 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=windows-1252 > On Mar 18, 2015, at 9:59 AM, Anthony Jenkins = wrote: >=20 > On 03/18/2015 11:26 AM, Warner Losh wrote: >> Looking at patch 5: >>=20 >> You need to rework this so there=92s an atrtc_acpi.c. Put all the = ACPI attachment in there. >=20 > Okay, shouldn't be a problem. >=20 >> You should also split off the little bit that=92s ISA-specific into = atrtc_isa. >=20 > You mean rtcin() and writertc()? ...but that's not my stuff, it was > already in atrtc.c. PNP0800 (the PC-AT RTC component) is = (practically) > an ISA-specific device. There will be a small =93isa=94 specific driver. Here ISA means =91FreeBSD= ISA attachment=92 not necessarily what you=92d find on an ISA bus. This means you=92d have two = separate driver statement. You can then do the ACPI stuff in the ACPI attachment and not = have to worry about whether or not it is compiled into the kernel, since you=92d only = include it if acpi is in the kernel. Warner --Apple-Mail=_A9D859D8-4CD7-4618-9C77-32F238BE7026 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP using GPGMail -----BEGIN PGP SIGNATURE----- Comment: GPGTools - https://gpgtools.org iQIcBAEBCgAGBQJVCe7YAAoJEGwc0Sh9sBEAMqEP/RDUi2VmhMFeV7W0+ssMGplt 9/QkjgivDPKvEbWDefm837nI2GY4FlIUIrN8F0r3D7Jr1Ur+NdJPsAimc4uOz/tG UHyG1QgOBG3GB0zuIYSwpJEPZ+ddlWH14vlucCjCoIm8FB1o/TKwHEUdU8OZtPMo 5DplTkwoUXo9vY9iJz+TpiwqR1KXVU5TKN22SrJcdkKLVFPWIpvCc2uXLrtkOp+x OR7v5q+1JxuKBSVSnehMKVeQwPbzBQA93dYswn/4a4kB4IK0oWgxpdHc0SvAt8vz AB/SlBWQySeB9QHQbSGRE8VxvTIFYmMHyAcBTdKS8ohf7JNi0zgHGNUHoer+HmW9 wcXFKR/y7tG6xiIDnH/yXlcQ/eQ3xXed/ZW/hG+cuKfoG8X0kd+bb0nQ99NeYFvG C10OGvew/2fk5yf2AobVtgzdxT3VL2mLGl1hqN6jJnpIfs4zAyOTFT/dg4UnZpIA rWD6mhBUd03GZ2OISEiLtI3m3AsQ4DDsjHRTXcMoa+rgCXISXcroHINax1e4FI5s IjPRfiswlmWFxaLnqoSwYPxfxvMbemeqDN3hCvIv6K6APVIPPGi31yDmL2O07U+R iF9Qvrf2f/g1VCXIkHsti53MV8qGwucUkwTzd4sUqKKPyg+AoNKq1gdcPORjd9qd L5wzrgal1kwpYDdBd7BS =+RsP -----END PGP SIGNATURE----- --Apple-Mail=_A9D859D8-4CD7-4618-9C77-32F238BE7026-- From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 08:11:05 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 19B104FF for ; Thu, 19 Mar 2015 08:11:05 +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 6F519935 for ; Thu, 19 Mar 2015 08:11:02 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2J8AfGD011554; Thu, 19 Mar 2015 19:10:41 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Thu, 19 Mar 2015 19:10:40 +1100 (EST) From: Ian Smith To: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 In-Reply-To: Message-ID: <20150319184348.X22641@sola.nimnet.asn.au> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> MIME-Version: 1.0 Content-ID: <20150319184542.U22641@sola.nimnet.asn.au> Content-Type: TEXT/PLAIN; CHARSET=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: Anthony Jenkins , freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 08:11:05 -0000 On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins wrote: > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins wrote: > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > >>> I'm picturing a (future?) config(5) knob, e.g. > >>> > >>> device atrtc > >>> options ATRTC_VERBOSE=1 > >>> > >>> > >>> so it can be set at compile time. > >> Why not just boot verbose? history has shown too many options like > >> this is hard to use. You can blame this on me :) I agree about the option not being needed; the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell reports of successful access, if it turns out these are routine on some machines, especially outside of boot/suspend/resume contexts. However I'll still argue that, this being a new gadget and that we could use finding out which vendors want to read or write which locations in CMOS for whatever reason, at least while it's in head, we should log all access by default unless setting atrtc_verbose=0, and in _any_ case we should be logging attempts to R/W out-of-bounds CMOS locations. > > I think I understand what you're saying... I also prefer fewer config(5) > > knobs. So you're suggesting I determine (at runtime) the boot verbose > > setting (kenv(2) or however it's properly done) and dump the > > compile-time verbosity setting? > > if (bootverbose) > do verbose things; > > is how that˙˙s done. Sure, and maybe successful access could be limited to bootverbose, and we could ask people whose boxes fail to boot/suspend/resume/whatever to boot verbose to reveal such as why Anthony's HP Envy either failed to suspend or immediately resumed - which isn't entirely clear, even with the messages - unless its ACPI AML succeeded in reading minute, hour and weekday, but I have a feeling we may see more of this sort of thing. cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 13:11:17 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id B8A8BDF3 for ; Thu, 19 Mar 2015 13:11:17 +0000 (UTC) Received: from nm12.bullet.mail.ne1.yahoo.com (nm12.bullet.mail.ne1.yahoo.com [98.138.90.75]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 759B6ED0 for ; Thu, 19 Mar 2015 13:11:16 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426770670; bh=AmpkyMRIAmOjUJPxUaox6qc6M/BJ4Nz3fBZY+GGDijU=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=rKgGRcw1kmOCLqhLTU3jUKs4ioTPyJKlZrtOJOyUx6f8/O+svcTRk7hi/1jkdG1uKKVoQ/zSnPQzL6wNoSOeFoED6xhDs9N4+HB+HgA1K+yWks2YO0wy+vZNEDIpENWI+VsoTJ+YRxjtVqKpmEuFj65EQmQo/M89jne/oUx3hXM= Received: from [98.138.226.180] by nm12.bullet.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:11:10 -0000 Received: from [98.138.226.130] by tm15.bullet.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:11:10 -0000 Received: from [127.0.0.1] by smtp217.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:11:10 -0000 X-Yahoo-Newman-Id: 235953.59350.bm@smtp217.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: b2OiB2wVM1m7izx63TRrzL04fr4_zF29OQFtO0lR50lxlqV v.pgHT3jxlMqhtCDAFuRhsRCjbVv44eYl35OrAlkUXCgi.FJJdZYd_.A5Wp8 .CTcgxceQvwEw6pcaLtdiyodtuZ2TWbWTLUfFD66H5KWkB6HyFSiWOjWMf.7 NFuEh1z3Jbf7kF8Y4zQgHjl6AUffv88ALGMKTjdmD8KakyNoxyr_DIyky71W TdCrB9osaCN5JhfrXGnHaFMGRMmus9w9rKSEjUPBoMUBUWqemeBZ1868XUUw axxLZ0x7rs7ex0BNqiLUnY2vtnQVBwz.XNtT_4Rj7Vd2L8LZL8SNo3nQqvWa DbvAuHf6XoBSSFn..F0RlK7I4vHovLDbRjdDQIGGOYbnTMmKxzDbgPBsSd7P Bk0y3_T8epKwvT8JUvfLzsSJOVDmpwxf3_qagoTzijyANDvc4bNq21zMv.Vp BnhTALw0WrVwkYpW8lqsV18rvGoaw4f1d11dWXU6QRFx.VjXRgVXK_.sU76C fX_dwQip.fWF2GHWDJ4bHOZSLfaAf.ODMgiYDNoMXeNYu97Vj X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <550ACAEC.3060808@att.net> Date: Thu, 19 Mar 2015 09:11:08 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith , Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> <20150319184348.X22641@sola.nimnet.asn.au> In-Reply-To: <20150319184348.X22641@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 13:11:17 -0000 On 03/19/2015 04:10 AM, Ian Smith wrote: > On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins wrote: > > > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins wrote: > > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > > >>> I'm picturing a (future?) config(5) knob, e.g. > > >>> > > >>> device atrtc > > >>> options ATRTC_VERBOSE=1 > > >>> > > >>> > > >>> so it can be set at compile time. > > >> Why not just boot verbose? history has shown too many options like > > >> this is hard to use. > > You can blame this on me :) I agree about the option not being needed; > the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell > reports of successful access, if it turns out these are routine on some > machines, especially outside of boot/suspend/resume contexts. > > However I'll still argue that, this being a new gadget and that we could > use finding out which vendors want to read or write which locations in > CMOS for whatever reason, at least while it's in head, we should log all > access by default unless setting atrtc_verbose=0, So the default verbosity of ACPI CMOS region accesses should be "verbose"? I personally don't mind the default being "silent" and asking people triaging an ACPI problem to boot verbosely and send the logs (I think that's in the FreeBSD ACPI handbook anyway). > and in _any_ case we > should be logging attempts to R/W out-of-bounds CMOS locations. Error logs are always printed; they don't honor atrtc_verbose. > > > I think I understand what you're saying... I also prefer fewer config(5) > > > knobs. So you're suggesting I determine (at runtime) the boot verbose > > > setting (kenv(2) or however it's properly done) and dump the > > > compile-time verbosity setting? > > > > if (bootverbose) > > do verbose things; > > > > is how that˙˙s done. > > Sure, and maybe successful access could be limited to bootverbose, and > we could ask people whose boxes fail to boot/suspend/resume/whatever to > boot verbose to reveal such as why Anthony's HP Envy either failed to > suspend or immediately resumed - which isn't entirely clear, even with > the messages - unless its ACPI AML succeeded in reading minute, hour and > weekday, but I have a feeling we may see more of this sort of thing. Now that I think about it, adding this ACPI CMOS region access should simply eliminate a class of failures where FreeBSD wasn't giving the BIOS access to CMOS. Logging /successful/ R/W accesses to CMOS by the BIOS (AML) won't really provide any useful info (IMHO), but the user can flip on bootverbose if she's curious. If a user's box fails to boot/suspend/resume/whatever, we'll see any ACPI CMOS region access errors. Anthony > cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 13:21:00 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id A7DA9FCE for ; Thu, 19 Mar 2015 13:21:00 +0000 (UTC) Received: from nm2-vm6.bullet.mail.ne1.yahoo.com (nm2-vm6.bullet.mail.ne1.yahoo.com [98.138.91.254]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 5EFE9F23 for ; Thu, 19 Mar 2015 13:20:59 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426771085; bh=QfDU+zIpL6TN+hg1xLB5+mZCw626O0fVg2NkmdEcKdQ=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=dNwriSwjgBTvLf6TCxJaKKe+mbmFmWKMLVS5RYq3NoxDq/YEe6G7CL6hpBQcNmfw/fVmbh0TvF0Xtk57NXZVBy4s3ZS+1cxJCdQvnn8pINsMhM5VujLM3+UreVB5cfAM6wsaIdm8bV5R0iOZUcxWJAYTISinnoPBElOosUeNciY= Received: from [98.138.226.179] by nm2.bullet.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:18:05 -0000 Received: from [98.138.84.44] by tm14.bullet.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:18:05 -0000 Received: from [127.0.0.1] by smtp112.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 13:18:05 -0000 X-Yahoo-Newman-Id: 36674.25531.bm@smtp112.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: x3zjA6MVM1nT.ciUoA1G6mN5eSiIz77rUEWpHsK_AnCZxF1 4pT2d1ezQ_uWNenn8gd5fmDQbuusV2hZrrkA02n7K8ojn9iT7NPW6uG4bMw4 ZaGxiTxANWq3fFmgil7M0GAuj7a8VLnAfdfp37oOiD2zW4dzgFkiC3kTbfgR j0yJ6BX_iqh5RuQD.olvIY_0on3PpAzA4Zp3Xv4orHlO7swpWyDIpU752kQN GVpkZjopb_3UvxxJm1hsykZmdDjAyoy67h3KoybXtrZsXqWDD_z6NUA4dY_2 nZRC56Q9fxvXj4LaUYZj6iLAUUTiNjC06aPzKUfX3XJLsDRMmmsUJiNa0_oG M.ghYw2r2314Jx22RCulVSGtgbnbd.EOywT_nZaJI_REyq.ArEP6gyLkLIrr Aqr3632Jw9YMqEA.u9Dxj02DxdP.hlMVQdv.ko2BKLNgAQj1aa9.Ubc2xc2F _3hFcfwDzNICqHDGWu9x7d83Drl3Rdcny4skCKb.4SxsQ.vUhnkMJJIRCYck FGwPTgeO3K_73AF_fA31l.IX4lkKqL1XmhNlpBp6u4HM7VaNG X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <550ACC8B.2090201@att.net> Date: Thu, 19 Mar 2015 09:18:03 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Warner Losh Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <5509A0EA.4070208@att.net> <85F2CFD2-14C1-43D6-8963-0D1F69F17577@bsdimp.com> In-Reply-To: <85F2CFD2-14C1-43D6-8963-0D1F69F17577@bsdimp.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Cc: freebsd-acpi@freebsd.org, Ian Smith X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 13:21:00 -0000 On 03/18/2015 05:32 PM, Warner Losh wrote: >> On Mar 18, 2015, at 9:59 AM, Anthony Jenkins wrote: >> >> On 03/18/2015 11:26 AM, Warner Losh wrote: >>> Looking at patch 5: >>> >>> You need to rework this so there’s an atrtc_acpi.c. Put all the ACPI attachment in there. >> Okay, shouldn't be a problem. >> >>> You should also split off the little bit that’s ISA-specific into atrtc_isa. >> You mean rtcin() and writertc()? ...but that's not my stuff, it was >> already in atrtc.c. PNP0800 (the PC-AT RTC component) is (practically) >> an ISA-specific device. > There will be a small “isa” specific driver. Here ISA means ‘FreeBSD ISA attachment’ not > necessarily what you’d find on an ISA bus. This means you’d have two separate driver > statement. You can then do the ACPI stuff in the ACPI attachment and not have to worry > about whether or not it is compiled into the kernel, since you’d only include it if acpi is > in the kernel. Okay I'll look for a simple example in the existing drivers...any suggestions? I was just hoping to leave atrtc(4) as intact as possible, adding an ACPI accessor for BIOSes that need it; this sounds like a reworking of atrtc(4)... Anthony > > Warner > From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 13:49:38 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 027335AD for ; Thu, 19 Mar 2015 13:49:37 +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 83AF824B for ; Thu, 19 Mar 2015 13:49:35 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id t2JDnMch022687; Fri, 20 Mar 2015 00:49:23 +1100 (EST) (envelope-from smithi@nimnet.asn.au) Date: Fri, 20 Mar 2015 00:49:22 +1100 (EST) From: Ian Smith To: Anthony Jenkins Subject: Re: [PATCH] ACPI CMOS region support rev. 5 In-Reply-To: <550ACAEC.3060808@att.net> Message-ID: <20150320002950.T22641@sola.nimnet.asn.au> References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> <20150319184348.X22641@sola.nimnet.asn.au> <550ACAEC.3060808@att.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=ISO-8859-1 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.18-1 Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 13:49:38 -0000 On Thu, 19 Mar 2015 09:11:08 -0400, Anthony Jenkins wrote: > On 03/19/2015 04:10 AM, Ian Smith wrote: > > On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins wrote: > > > > > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins wrote: > > > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > > > >>> I'm picturing a (future?) config(5) knob, e.g. > > > >>> > > > >>> device atrtc > > > >>> options ATRTC_VERBOSE=1 > > > >>> > > > >>> > > > >>> so it can be set at compile time. > > > >> Why not just boot verbose? history has shown too many options like > > > >> this is hard to use. > > > > You can blame this on me :) I agree about the option not being needed; > > the way it is you can just set sysctl hw.acpi.atrtc_verbose=0 to quell > > reports of successful access, if it turns out these are routine on some > > machines, especially outside of boot/suspend/resume contexts. > > > > However I'll still argue that, this being a new gadget and that we could > > use finding out which vendors want to read or write which locations in > > CMOS for whatever reason, at least while it's in head, we should log all > > access by default unless setting atrtc_verbose=0, > > So the default verbosity of ACPI CMOS region accesses should be > "verbose"? I personally don't mind the default being "silent" and > asking people triaging an ACPI problem to boot verbosely and send the > logs (I think that's in the FreeBSD ACPI handbook anyway). Assuming they know that their problem is ACPI related, sure. > > and in _any_ case we > > should be logging attempts to R/W out-of-bounds CMOS locations. > > Error logs are always printed; they don't honor atrtc_verbose. That would be comforting. However I was referring to rev. 5: + if (bitwidth == 0 || bitwidth > 32 || (bitwidth & 0x07) || + addr + bytewidth - 1 > 63) { + ATRTC_DBG_PRINTF(1, + "Invalid bitwidth (%u) or addr (0x%08lx).\n", + bitwidth, addr); + return AE_BAD_PARAMETER; + } + if (!acpi_check_rtc_access(func == ACPI_READ, addr, bytewidth)) { + ATRTC_DBG_PRINTF(1, "Bad CMOS %s access at addr 0x%08lx.\n", + func == ACPI_READ ? "read" : "write", addr); + return AE_BAD_PARAMETER; + } > > > > I think I understand what you're saying... I also prefer fewer config(5) > > > > knobs. So you're suggesting I determine (at runtime) the boot verbose > > > > setting (kenv(2) or however it's properly done) and dump the > > > > compile-time verbosity setting? > > > > > > if (bootverbose) > > > do verbose things; > > > > > > is how that˙˙s done. > > > > Sure, and maybe successful access could be limited to bootverbose, and > > we could ask people whose boxes fail to boot/suspend/resume/whatever to > > boot verbose to reveal such as why Anthony's HP Envy either failed to > > suspend or immediately resumed - which isn't entirely clear, even with > > the messages - unless its ACPI AML succeeded in reading minute, hour and > > weekday, but I have a feeling we may see more of this sort of thing. > > Now that I think about it, adding this ACPI CMOS region access should > simply eliminate a class of failures where FreeBSD wasn't giving the > BIOS access to CMOS. Do we have other examples than your HP Envy of such a class of failures? > Logging /successful/ R/W accesses to CMOS by the > BIOS (AML) won't really provide any useful info (IMHO), but the user can > flip on bootverbose if she's curious. If a user's box fails to > boot/suspend/resume/whatever, we'll see any ACPI CMOS region access errors. Well I've made a case otherwise, likely too avidly; I'll leave it there. Thanks for flushing out this issue and doing something about it! cheers, Ian From owner-freebsd-acpi@FreeBSD.ORG Thu Mar 19 14:14:18 2015 Return-Path: Delivered-To: freebsd-acpi@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id C3114E09 for ; Thu, 19 Mar 2015 14:14:18 +0000 (UTC) Received: from nm3.bullet.mail.gq1.yahoo.com (nm3.bullet.mail.gq1.yahoo.com [98.136.218.68]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 87A0F7A6 for ; Thu, 19 Mar 2015 14:14:18 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=att.net; s=s1024; t=1426774457; bh=kHdsZ9ZrVLKGCRXK3rgLmMGai9tmmCrtCWL1RlceqAE=; h=Date:From:To:CC:Subject:References:In-Reply-To:From:Subject; b=Zi6CNEY+GZ/tGmhVua9e9GC56FMLtc6T3LgQV+0lFWRI9yLCH20IPV2gQzZGlFR0nf8C70IYFwKUSUWIGciie+XSbclIA9xNZ3GAJ0x1mbJF5rdVOdhIoCuAylUTnnnBr441qXkjGvReKQTWiqMekSoq7A5fPM3noVmHxJvaAH4= Received: from [98.137.12.190] by nm3.bullet.mail.gq1.yahoo.com with NNFMP; 19 Mar 2015 14:14:17 -0000 Received: from [98.138.226.63] by tm11.bullet.mail.gq1.yahoo.com with NNFMP; 19 Mar 2015 14:14:17 -0000 Received: from [127.0.0.1] by smtp214.mail.ne1.yahoo.com with NNFMP; 19 Mar 2015 14:14:16 -0000 X-Yahoo-Newman-Id: 946683.9164.bm@smtp214.mail.ne1.yahoo.com X-Yahoo-Newman-Property: ymail-3 X-YMail-OSG: O_qPvXoVM1k38tW14eEbZdqWSNsv66Svbl7H9ima..fGeS3 2doBmzjOveuexmj_NhBun2_6cQXi8OvG58X2UzVfX5cloC30hcH8uA7Dhmby 95d8vklHo042mcVCdHZF_BtFmMcrzfPZ2HZz9wLyNlIohXm0.E_9z8pp7V78 W8Zm.B4Urp_b7fjqBA.t6EfqYqAFhvV5xXbfp.KmFoDHpBVctzvaXXEP9wpR h38xzX9zvZApARPaaU1hOT.eKuoaSmms_3OYUhKUxp7D7A64CHcuvKugndZ1 LZNCEB76rubxFFg3qLxYTQb0embWjXPygq.PAPQjj1l4IGsGk2W.9cxCmo.g sirUprFoAj3EZhK3ZNhiPdAHgGpNLzwK1ct9Tg81Y678NJdlTNrY6aySTDXE B4odS9mJUy3XnkI9.gABGcN21tSwPsyy8HFQMn2u6c8u8i361SoWlxQAG5Sc Ria0Y81_C4Gwv4cQTIjZ9X1ozb4Dsb5S3etPdOsn4exr9U5XmJaE_PyS1Nel C1yRQfkPa0Atm6s9oVvyzLgvIL2iuDAVQhG6Scr0p7VZRyJ4B X-Yahoo-SMTP: OKD1keCswBBTAmAF1s00hLyKW3wE3YfSK0Eazl6b4VZG4LTqJxg- Message-ID: <550AD9B7.4090508@att.net> Date: Thu, 19 Mar 2015 10:14:15 -0400 From: Anthony Jenkins User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.5.0 MIME-Version: 1.0 To: Ian Smith Subject: Re: [PATCH] ACPI CMOS region support rev. 5 References: <20150222180817.GD27984@strugglingcoder.info> <54EB8C21.2080600@att.net> <2401337.2oUs7iAbtB@ralph.baldwin.cx> <54EF3D5D.4010106@att.net> <20150227222203.P38620@sola.nimnet.asn.au> <20150228125857.D1277@besplex.bde.org> <54F14368.4020807@att.net> <20150302002647.W42658@sola.nimnet.asn.au> <54F5E53D.1090601@att.net> <20150306025800.U46361@sola.nimnet.asn.au> <54F9D7E6.4050807@att.net> <5504FF32.3020202@att.net> <20150317001401.X22641@sola.nimnet.asn.au> <5506F00A.3030708@att.net> <5506FBE3.1000009@att.net> <20150317041624.K22641@sola.nimnet.asn.au> <55073442.5060005@att.net> <20150317222704.K22641@sola.nimnet.asn.au> <550825DE.7030406@att.net> <56B494A3-2058-4B7B-8183-646A46753A53@bsdimp.com> <5509A282.6070207@att.net> <20150319184348.X22641@sola.nimnet.asn.au> <550ACAEC.3060808@att.net> <20150320002950.T22641@sola.nimnet.asn.au> In-Reply-To: <20150320002950.T22641@sola.nimnet.asn.au> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable Cc: freebsd-acpi@freebsd.org X-BeenThere: freebsd-acpi@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: ACPI and power management development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 19 Mar 2015 14:14:18 -0000 On 03/19/2015 09:49 AM, Ian Smith wrote: > On Thu, 19 Mar 2015 09:11:08 -0400, Anthony Jenkins wrote: > > On 03/19/2015 04:10 AM, Ian Smith wrote: > > > On Wed, 18 Mar 2015 15:30:23 -0600, Warner Losh wrote: > > > > > On Mar 18, 2015, at 10:06 AM, Anthony Jenkins wrote: > > > > >=20 > > > > > On 03/18/2015 11:29 AM, Warner Losh wrote: > > > > >>> On Mar 17, 2015, at 7:02 AM, Anthony Jenkins wrote: > > > > >>>> \Where else might ATRTC_VERBOSE be set otherwise? > > > > >>> I'm picturing a (future?) config(5) knob, e.g. > > > > >>>=20 > > > > >>> device atrtc > > > > >>> options ATRTC_VERBOSE=3D1 > > > > >>>=20 > > > > >>>=20 > > > > >>> so it can be set at compile time. > > > > >> Why not just boot verbose? history has shown too many option= s like > > > > >> this is hard to use. > > > > > > You can blame this on me :) I agree about the option not being ne= eded;=20 > > > the way it is you can just set sysctl hw.acpi.atrtc_verbose=3D0 to= quell=20 > > > reports of successful access, if it turns out these are routine on= some=20 > > > machines, especially outside of boot/suspend/resume contexts. > > > > > > However I'll still argue that, this being a new gadget and that we= could=20 > > > use finding out which vendors want to read or write which location= s in=20 > > > CMOS for whatever reason, at least while it's in head, we should l= og all=20 > > > access by default unless setting atrtc_verbose=3D0, > >=20 > > So the default verbosity of ACPI CMOS region accesses should be > > "verbose"? I personally don't mind the default being "silent" and > > asking people triaging an ACPI problem to boot verbosely and send th= e > > logs (I think that's in the FreeBSD ACPI handbook anyway). > > Assuming they know that their problem is ACPI related, sure. > > > > and in _any_ case we=20 > > > should be logging attempts to R/W out-of-bounds CMOS locations. > >=20 > > Error logs are always printed; they don't honor atrtc_verbose. > > That would be comforting. However I was referring to rev. 5: > > + if (bitwidth =3D=3D 0 || bitwidth > 32 || (bitwidth & 0x07) || > + addr + bytewidth - 1 > 63) { > + ATRTC_DBG_PRINTF(1, > + "Invalid bitwidth (%u) or addr (0x%08lx).\n", > + bitwidth, addr); > + return AE_BAD_PARAMETER; > + } > + if (!acpi_check_rtc_access(func =3D=3D ACPI_READ, addr, bytewid= th)) { > + ATRTC_DBG_PRINTF(1, "Bad CMOS %s access at addr 0x%08lx= =2E\n", > + func =3D=3D ACPI_READ ? "read" : "write", addr)= ; > + return AE_BAD_PARAMETER; > + } Ahh you're right, my bad. These are /supposed/ to be simple printf()s (or ATRTC_DBG_PRINTF(0, ...)s, but I think this would trigger a "unsigned int >=3D 0 is always true" warning). > > > > > I think I understand what you're saying... I also prefer fewe= r config(5) > > > > > knobs. So you're suggesting I determine (at runtime) the boo= t verbose > > > > > setting (kenv(2) or however it's properly done) and dump the > > > > > compile-time verbosity setting? > > > >=20 > > > > if (bootverbose) > > > > do verbose things; > > > >=20 > > > > is how that=FF=FFs done. > > > > > > Sure, and maybe successful access could be limited to bootverbose,= and=20 > > > we could ask people whose boxes fail to boot/suspend/resume/whatev= er to=20 > > > boot verbose to reveal such as why Anthony's HP Envy either failed= to=20 > > > suspend or immediately resumed - which isn't entirely clear, even = with=20 > > > the messages - unless its ACPI AML succeeded in reading minute, ho= ur and=20 > > > weekday, but I have a feeling we may see more of this sort of thin= g. > >=20 > > Now that I think about it, adding this ACPI CMOS region access shoul= d > > simply eliminate a class of failures where FreeBSD wasn't giving the= > > BIOS access to CMOS. > > Do we have other examples than your HP Envy of such a class of failures= ? Oh definitely! You should be able to search for my name in this newsgroup and find instances where I've manually provided the patch to someone having suspend/resume issues and they've been resolved. One has subject "Impossible shutdown" circa 2014-June-26. Anthony > > Logging /successful/ R/W accesses to CMOS by the > > BIOS (AML) won't really provide any useful info (IMHO), but the user= can > > flip on bootverbose if she's curious. If a user's box fails to > > boot/suspend/resume/whatever, we'll see any ACPI CMOS region access = errors. > > Well I've made a case otherwise, likely too avidly; I'll leave it there= =2E > > Thanks for flushing out this issue and doing something about it! > > cheers, Ian > _______________________________________________ > freebsd-acpi@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-acpi > To unsubscribe, send any mail to "freebsd-acpi-unsubscribe@freebsd.org"=