| Age | Commit message (Collapse) | Author |
|---|
|
that's ever used it, and it's long since been changed to use
DVACT_{QUIESCE,SUSPEND,RESUME} instead.
ok deraadt@, dlg@; miod@ also agreed with this idea when I brought it
up a few weeks ago
|
|
them from userland, and nothing in the kernel uses them.
ok krw@, miod@
|
|
ok jakemsr@
|
|
usbd_deactivete() and usbd_is_dying()
* use usbd_deactivate() in activate()/DEACTIVATE
* convert a few more direct checks of the associated bus' dying flag
with usbd_is_dying()
|
|
ok phessler
|
|
be run from the generic task kthread, because xfers that need to be
aborted block newly queued tasks from running (i.e. the xfer to be aborted
blocks the abort of that task). as there are now three types of usb
tasks, add an argument to usb_init_task() and another member to struct
usb_task to specify the task type.
fixes boot hangs that are showing up because we now use usb tasks to
attach/detach usb devices.
|
|
The dying flag will be set in activate()/DEACTIVATE.
ok deraadt@
|
|
This is needed for the addition of further suspend/resume actions.
Okay deraadt@, marco@.
|
|
since autoconf(9) allocates softc with M_ZERO; ok deraadt
|
|
|
|
when usb_lookup is used. If a device indeed has 0 as vendor and product
ID, like the HP DL165 BMC Server Engines SE USB Device, a wrong driver
will attach and the machine will most pbly crash.
Problem reported Rivo Nurges <rix@estpak.ee>
cvs: ----------------------------------------------------------------------
|
|
|
|
FT232R chip to interface the receiver (instead of the NetCologne
chip used on older models). Only the DCF77 and HBG receivers are
supported.
A sidenote: Gude ADS not only provides me with receivers and
documentation, but as a result of my feedback on their older receivers
the new ones now have proper USB product IDs to distinguish between
DCF77, HBG, and MSF.
|
|
Discussed with dlg.
|
|
Discussed with kettenis.
|
|
so that it shows up before the :. as a result, all the usb devices do not
need to have name printing code anymore. all this now works and prints
nicely because usbd_probe_and_attach() is serialized. ok kettenis
|
|
USB_DECLARE_DRIVER macros.
No binary change.
ok dlg.
|
|
No binary change.
ok mk.
|
|
(This might look easy, but it was a big diff. Thanks to dlg and especially jsg
for looking over it; we found at least four mistakes in the initial diff.)
ok jsg.
|
|
and the address of it's argument: USBDEV(sc->sc_dev) yields &sc->sc_dev.
No binary changes.
ok jsg.
|
|
Tested by thib and myself.
ok mbalmer jsg
|
|
ok deraadt@ krw@ mbalmer@
|
|
|
|
|
|
of new fields in the future is less disruptive. This is done similar
to how struct proc is handled for ps(1). ok jmc (man page changes)
tested fkr simon, and more suggestions from millert
|
|
|
|
|
|
|
|
immediately following the corrupt one; there is no no need to skip it by
waiting for the next minute gap and the sensor value has valid data one
minute earlier than before.
|
|
prevents the signal loss function from being called repeatedly when we have
no signal.
|
|
Only look at the skew value if it is != 0.
Remove some dead code.
|
|
udcfdebug > 1.
|
|
naddy; many thanks to naddy for continous testing and feedback during the
last weeks.
ok naddy
|
|
Problem and solution found by Christian "Naddy" Weisgerber <naddy@openbsd.org>,
thanks!
|
|
just t1-t10.
- Remove some unused variables.
- Restructure some functions to remove some levels of indentation.
|
|
error, which is to fast as this does not give ntpd the opportunity to use the
sensor value.
If we decode a valid time information, it has to be available to applications
for some minimal time. I choose a value of 5 minutes. If we do not receive
any new valid time information during this period, the sensor will be degraded
to WARNING, and after another fifteen minutes it will be further degraded to
CRITICAL.
"makes sense to me" henning@, "sure" deraadt@
|
|
|
|
status of SENSOR_S_UNKNOWN. Do not set the SENSOR_FINVALID bit, sysctl
hw.sensors does not list sensors with this flags set and we want to the sensor
when the device is present.
ok henning
|
|
something, then it MUST return zero on DVACT_ACTIVATE, not EOPNOTSUPP;
this very popular bug has been cut and pasted a lot of times...
ok deraadt@ mickey@
|
|
sys/kern/clock_subr.c
|
|
so that things can use it; tested on all architectures; ok kettenis
|
|
to the kernel, the two functions it used from this file are now included in
the driver itself (like in nmea(4)). udcf(4) can now be enabled to the zaurus,
too. in fact on all arches that have USB support.
|
|
|
|
|
|
description.
- create the timedelta sensors as early as possible, but mark them invalid
as long as there is no real data.
- update docs accordingly
|
|
the NTP identifier (filled with spaces), followed by a space and the station
name (which might be the same as the NTP identifier).
All timedelta sensor have to follow this scheme as OpenNTPD needs it.
Requested by henning.
|
|
framework will create hotplug events for sensor addition/deletion. ntpd
will catch these events.
|
|
SENSOR_FINVALID flag set and without a description. We do not need a dummy
description as a sensor with the FINVALID flags set will not show up or be used
anyways. It's merely an indication to applications that there is a sensor that
will eventually have a correct value.
The SENSOR_FINVALID flag is removed and the description is set to the proper
clockname as soon as we have received the first valid time information.
This enables ntpd to check for hotplug events and rescan the list of timedelta
sensors after a hotplug event.
discussed with deraadt.
|
|
- provide the timedelta in nanoseconds
- provide a timestamp in the sensor
support for HBG and DCF77:
- detect clocktype (DCF77 or HBG) and set it once is the sensor description
|
|
help and ok kettenis@
|
