Change the `attached` member of `struct comedi_device` to a 1-bit
bit-field of type `bool`. Change assigned values to `true` and `false`
and replace or remove comparison operations with simple boolean tests.
We'll put some extra bit-fields in the gap later to save space.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Florent Boudet reports success using a NI PXI-6624 board with a
trivially modified version of the "ni_660x" driver (addition to the PCI
device ID table and comedi board table). He did this with the
out-of-tree Comedi drivers at www.comedi.org, but it applies equally to
the in-tree "staging" drivers.
He reports the PXI-6624 is basically the same as the PXI-6602, but with
isolated channels and external voltage source.
Add support for NI PXI-6224 to the "ni_660x" driver.
(Maybe the driver should be renamed to "ni_66xx"?)
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: Florent Boudet <flboudet@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Back in the old days (before "staging") when Comedi only supported
manual configuration of devices, the "adv_pci_dio" driver supported both
PCI-1753 ("pci1753") and PCI-1753E ("pci1753e"). In actual fact,
"pci1753e" is just a PCI-1753 connected by a ribbon cable to a PCI-1753E
expansion card, which is plugged into a PCI slot but is not a PCI device
itself. Now that the "adv_pci_dio" driver only supports automatic
configuration of devices and the main "comedi" module no longer allows
auto-configuration to be disabled, a PCI-1753 with a PCI-1753E expansion
card is always treated as an unexpanded PCI-1753 ("pci1753") and there
is no way to override it. (Recently, an undefined macro
`USE_PCI1753E_BOARDINFO` was used to make the driver switch to
supporting "pci1753e" instead of "pci1753", but this is less than
ideal.)
Advantech has their own Linux (non-Comedi) driver for the PCI-1753 which
detects whether the PCI-1753E expansion card is connected to the
PCI-1753 by fiddling with a register at offset 53 from the main
registers base.
Use Advantech's test in our "adv_pci_dio" driver. If the board appears
to be a PCI-1753 ("pci1753"), check if the expansion card appears to be
present, and if so, treat the device as a PCI-1753 plus PCI-1753E
expansion card ("pci1753e").
Also, get rid of `enum dio_boardid` (`BOARD_...` enum values) which was
added recently and just use the older `TYPE_...` enum values from `enum
hw_cards_id` instead as the mapping is now 1-to-1.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
dwc2_hcd_release() calls dwc2_hcd_free() which frees ->core_params
and sets it to NULL.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
'lli_array_ptr' etc. are malloced in sep_prepare_input_dma_table() and should
be freed before leaving from the error handling case, otherwise it will cause
memory leak.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Not all APIs exposed today are used. However all unused APIs
will be required once the thermal layer allows IRQ based
policies.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It is hard to use regmap because benefit of using regmap cache
may not be applicable as there is a specific sequence to
restore the bandgap context.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Because there is a need to lock inside IRQ handler, this patch
changes the locking mechanism inside the omap-bandgap.[c,h] to
spinlocks. Now this lock is used to protect omap_bandgap struct
during APIs exposed (possibly used in sysfs handling functions)
and inside the ALERT IRQ handler.
Because there are registers shared among the sensors, this lock
is global, not per sensor.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Now arch code has to specify CONFIG_ARCH_HAS_BANDGAP. So, this driver
will be selectable only if the platform reports itself as having a
bandgap device.
Any OMAP variant or any other OMAP version needs to
select ARCH_HAS_BANDGAP
so that the driver will be applicable. A part from that it is
required to device the data structures that maps the registers
and their bitfields. The DT compatible list must also be updated.
CC: Santosh Shilimkar <santosh.shilimkar@ti.com>
CC: Vaibhav Bedia <vaibhav.bedia@ti.com>
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch names 'enable_continuous_mode' accordingly to the file
standard naming.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This patch improves the code that handles threshold values
by creating single functions that are usable for tcold and
thot. This way we won't have duplicated functionality just
because it is handling different bitfields. Now
the added functions are reused in several places where
it is needed to update any threshold.
This patch also removes macros that are used only inside
the _validate helper function.
In this patch there is also an addition of an extra function
section for Exposed APIs, used outside the omap-bandgap.c,
but inside the omap-thermal driver.
Signed-off-by: Eduardo Valentin <eduardo.valentin@ti.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>