[PATCH] ACPI CMOS region support rev. 4
Anthony Jenkins
Anthony.B.Jenkins at att.net
Mon Mar 16 15:02:58 UTC 2015
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 at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscribe at freebsd.org"
More information about the freebsd-acpi
mailing list