10 Mar, 2019
1 commit
-
commit 82f844c22588bf47132c82faeda50b6db473162c upstream.
Make sure the receiver is powered (and booted) before enabling the
wakeup interrupt to avoid spurious interrupts due to a floating input.Similarly, disable the interrupt before powering off on probe errors and
on unbind.Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers")
Cc: stable # 4.19
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
13 Dec, 2018
1 commit
-
commit 06fd9ab12b804451b14d538adbf98a57c2d6846b upstream.
Fix activation helper which would return -ETIMEDOUT even if the last
retry attempt was successful.Also change the semantics of the retries variable so that it actually
holds the number of retries (rather than tries).Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers")
Cc: stable # 4.19
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
27 Nov, 2018
2 commits
-
commit 1decef370456870bf448a565be95db636428e106 upstream.
Passing a timeout of zero to the synchronous serdev_device_write()
helper does currently not imply to wait forever (unlike passing zero to
serdev_device_wait_until_sent()). Instead, if there's insufficient
room in the write buffer, we'd end up with an incomplete write.Fixes: d2efbbd18b1e ("gnss: add driver for sirfstar-based receivers")
Cc: stable # 4.19
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
commit 56a6c7268312cba9436b84cac01b3e502c5c511d upstream.
Passing a timeout of zero to the synchronous serdev_device_write()
helper does currently not imply to wait forever (unlike passing zero to
serdev_device_wait_until_sent()). Instead, if there's insufficient
room in the write buffer, we'd end up with an incomplete write.Fixes: 37768b054f20 ("gnss: add generic serial driver")
Cc: stable # 4.19
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
16 Jul, 2018
2 commits
-
The gnss_allocate_device() function returns a mix of NULL and error
pointers on error. It should only return one or the other. Since the
callers both check for NULL, I've modified it to return NULL on error.Fixes: 2b6a44035143 ("gnss: add GNSS receiver subsystem")
Signed-off-by: Dan Carpenter
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
The structure ubx_gserial_ops is local to the source and does not need
to be in global scope, so make it static.Cleans up sparse warning:
symbol 'ubx_gserial_ops' was not declared. Should it be static?Signed-off-by: Colin Ian King
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman
28 Jun, 2018
5 commits
-
Add a "type" device attribute and a "GNSS_TYPE" uevent variable which
can be used to determine the type of a GNSS receiver. The currently
identified types reflect the protocol(s) supported by a receiver:"NMEA" NMEA 0183
"SiRF" SiRF Binary
"UBX" UBXNote that both SiRF and UBX type receivers typically support a subset of
NMEA 0183 with vendor extensions (e.g. to allow switching to the vendor
protocol).Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
Add driver for serial-connected SiRFstar-based GNSS receivers.
These devices typically boot into hibernate mode from which they can be
woken using a pulse on the ON_OFF input pin. Once active, a pulse on the
same ON_OFF pin is used to put the device back into hibernate mode. The
current state can be determined by sampling the WAKEUP output.Hardware configurations where WAKEUP has been connected to ON_OFF (and
where an initial WAKEUP pulse during boot is sufficient to have the
device boot into active mode) are also supported. In this case, device
power is managed using the main-supply regulator only.Note that configurations where WAKEUP is left not connected, so that the
device power state can only indirectly be determined using the I/O
interface, is currently not supported. It should be fairly
straight-forward to extend the current implementation with such support
however (and this this is the main reason for not using the generic
serial implementation for this driver).Note that timepulse-support is left unimplemented.
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
Add driver for serial-connected u-blox GNSS receivers.
Note that the driver uses the generic GNSS serial implementation and
therefore essentially only manages power abstracted into three power
states: ACTIVE, STANDBY, and OFF.For u-blox receivers with a main supply and no enable-gpios, this simply
means that the main supply is disabled in STANDBY and OFF (the optional
backup supply is kept enabled while the driver is bound).Note that timepulse-support is not yet implemented.
Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
Add a generic serial GNSS driver (library) which provides a common
implementation for the gnss interface and power management (runtime and
system suspend). This allows GNSS drivers for specific chip to be
implemented by simply providing a set_power() callback to handle three
states: ACTIVE, STANDBY and OFF.Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman -
Add a new subsystem for GNSS (e.g. GPS) receivers.
While GNSS receivers are typically accessed using a UART interface they
often also support other I/O interfaces such as I2C, SPI and USB, while
yet other devices use iomem or even some form of remote-processor
messaging (rpmsg).The new GNSS subsystem abstracts the underlying interface and provides a
new "gnss" class type, which exposes a character-device interface (e.g.
/dev/gnss0) to user space. This allows GNSS receivers to have a
representation in the Linux device model, something which is important
not least for power management purposes.Note that the character-device interface provides raw access to whatever
protocol the receiver is (currently) using, such as NMEA 0183, UBX or
SiRF Binary. These protocols are expected to be continued to be handled
by user space for the time being, even if some hybrid solutions are also
conceivable (e.g. to have kernel drivers issue management commands).This will still allow for better platform integration by allowing GNSS
devices and their resources (e.g. regulators and enable-gpios) to be
described by firmware and managed by kernel drivers rather than
platform-specific scripts and services.While the current interface is kept minimal, it could be extended using
IOCTLs, sysfs or uevents as needs and proper abstraction levels are
identified and determined (e.g. for device and feature identification).Signed-off-by: Johan Hovold
Signed-off-by: Greg Kroah-Hartman