| created | 2021-04-04T01:50:48Z |
|---|---|
| begin | 2021-04-01T00:00:00Z |
| end | 2021-04-02T00:00:00Z |
| path | src/sys |
| commits | 3 |
| date | 2021-04-01T08:39:52Z | |||
|---|---|---|---|---|
| author | mvs | |||
| files | src/sys/dev/usb/if_umb.c | log | diff | annotate |
| message |
Push kernel lock down to umb_rtrequest(). We are going to unlock PF_ROUTE sockets. This means `if_rtrequest' handler will be performed without kernel lock. umb_rtrequest() calls umb_send_inet_proposal() which touches kernel lock protected `ipv{4,6}dns' array. Also umb_rtrequest() is the only handler which requires kernel lock to be held. So push the lock down to umb_rtrequest() instead of grab it around `if_rtrequest' call. This hunk was commited separately for decreases PF_ROUTE sockets unlocking diff. ok gerhard@ deraadt@ |
|||
| date | 2021-04-01T10:34:21Z | |||
|---|---|---|---|---|
| author | kn | |||
| files | src/sys/dev/fdt/cwfg.c | log | diff | annotate |
| message |
Hardcode meaningful alert level, track apm's battery state better The current code looks for the nonexistent "cellwise,alert-level" property and falls back to zero as threshold (like the original NetBSD code). It also updates the CONFIG register with that very threshold to let the hardware set a bit and thus alert us when it has been reached. Since our sensor framework is designed to poll every N seconds and this driver does not actually look at whether the hardware alerted, neither using a default threshold of zero nor updating the hardware with it makes sense. Remove the alert level code and simply map >50%, >25% and <=25% of remaining battery life to apm(4)'s "high", "low" and "critical" battery state respectively; this matches exactly what acpibat(4) does and provides more meaningful sensor readings without relying on nonexistent device tree bindings. Feedback OK patrick |
|||
| date | 2021-04-01T12:06:00Z | |||
|---|---|---|---|---|
| author | kn | |||
| files | src/sys/dev/fdt/cwfg.c | log | diff | annotate |
| message |
Clean up nonexistent/unused properties handling Never used since import and probably just ported over from NetBSD as-is; "design-capacity" does not exist in the device tree binding. "monitor-interval-ms" defaults to 250ms as per binding and could be used in the sensor_task_register() call, but our framework only supports whole seconds and there's no advantage over our current fixed poll interval of 5s. OK patrick |
|||