When setting up an encoder channel, the setup value includes a polarity
and direction, but these are the same bit of the setup value:
S626_CLKPOL_POS = S626_CNTDIR_UP = 0
S626_CLKPOL_NEG = S626_CNTDIR_DOWN = 1
In the construction of the setup value, both the CLKPOL and the CNTDIR
constants are shifted by the same amount `S626_BF_CLKPOL`. Only the
following combinations are set up currently (this may change if user
configuration of the encoder is implemented properly):
(S626_CLKPOL_POS << S626_BF_CLKPOL)
(S626_CLKPOL_POS << S626_BF_CLKPOL) |
(S626_CNTDIR_UP << S626_BF_CLKPOL)
(S626_CLKPOL_POS << S626_BF_CLKPOL) |
(S626_CNTDIR_DOWN << S626_BF_CLKPOL)
The first two are used in "counter" mode and is equivalent to:
(S626_CLKPOL_POS << S626_BF_CLKPOL)
The last one is used in "timer" mode and is equivalent to:
(S626_CNTDIR_DOWN << S626_BF_CLKPOL)
Use the shorter equivalents. The comments in "s626.h" indicate that the
'CLKPOL' constants make more sense for the "counter" mode (when the
encoders operate as up/down counters) and the 'CNTDIR' constants make
more sense for the "timer" mode.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The `unsigned char chan_is_bipolar[]` member of `struct rtd_private` is
used with some macros as a packed array of 1-bit values that indicate
whether the corresponding entries in the hardware's "channel-gain" table
have been set to a bipolar (1) or unipolar (0) range, as the raw samples
from the hardware need to be cooked differently in each case.
Replace the declaration of the member with a standard Linux bitfield
using `DECLARE_BITFIELD()`, and replace the home-grown macros used
access the bitfield with the standard Linux non-atomic bitop functions,
`__set_bit()`, `__clear_bit()` and `test_bit()`.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed two coding style issues, specifically:
ft1000_proc.c:35: ERROR: space required before the open parenthesis '('
ft1000_proc.c:42: ERROR: space required before the open parenthesis '('
Signed-off-by: Aldo Iljazi <me@aldo.io>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
This is necessary so that xillybus_core uses the correct device pointer
for PCIe devices in diagnostic message calls (dev_err, dev_warn and dev_info)
Signed-off-by: Eli Billauer <eli.billauer@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary spaces between function names and open
parentheses in router_proc.c to meet kernel coding style.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reformat a pointer variable in lib-move.c to meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary parentheses from return statements to
eliminate errors generated by checkpatch.pl and meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fixed lines to not exceed more than 80 columns per line to meet
kernel coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Move open braces to previous lines in lib-move.c to meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove unnecessary whitespace around open parentheses in lib-move.c
to meet kernel coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Remove spaces between function names and open parentheses to
eliminate warnings generated by checkpatch.pl and meet kernel
coding standards.
Signed-off-by: Lisa Nguyen <lisa@xenapiadmin.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix the following sparse warning:
drivers/staging/rtl8192u/ieee80211/ieee80211_tx.c:240:22: warning: symbol 'ieee80211_alloc_txb' was not declared. Should it be static?
Signed-off-by: Teodora Baluta <teobaluta@gmail.com>
Reviewed-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Reviewed-by: Josh Triplett <josh@joshtriplett.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch warning: WARNING: Comparing jiffies is almost always
wrong; prefer time_after, time_before and friends
Signed-off-by: Ashvini Varatharaj <ashvinivaratharaj@gmail.com>
Reviewed-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch warning: Comparing jiffies is almost always wrong;
prefer time_after, time_before and friends
Signed-off-by: Ashvini Varatharaj <ashvinivaratharaj@gmail.com>
Reviewed-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
New Drivers
* cm36651 combined RGB light and proximity sensor.
Core improvements
* Some more fixes and cleanups related to buffers. These include the second
half of a series which went is as fixes. The basis for delaying until the
next merge window is that some are too invasive for this late in a cycle
and others only effect code paths current unused in the mainline tree.
In this case we have:
* protecting against concurrent userspace access
* fixing a memory leak if a device goes away
* avoiding always reallocating the buffer whether or not it has changed
(a bug fix, but one with no functional changes other than a small speed
improvement.)
* Add reference counting for buffers to ensure they hang around if open
from userspace or in kernel when the device is forcefully removed.
* Return -ENODEV for buffer access operations when the device has gone
away.
* Add proper locking for iio_update_buffers (currently we only have one
buffer per device in mainline, but an input bridge driver is under
development which would make this bug 'real'.)
* Wake up anyone waiting on a buffer if the device is unregistered. A
subsequent read will fail, notifying userspace that the device is no
longer there rather than having it wait possibly for ever.
* Move the iio_sw_preenable functionality into the core. This avoids drivers
having to 'know' about how the buffers are implemented and is called by
almost all drivers anyway. Those that don't call it are not harmed by it
being called.
* New registration approach for information (i.e. sysfs attributes) about
events. Much more generic and now similar to how the equivalent is
handled for channel information. The events infrastructure had been left
behind by other changes so this brings it back in line.
* Using the new events registration approach, add a hysterisis event_info
element and apply this to those drivers with this property.
* A little unitialized variable bug in the generic_buffer.c example.
* Factor out the code for freeing lists of IIO Device attributes to avoid
some repitition.
Driver cleanups
* At91 driver gains touch screen support and some related fixes.
* Follow up series of patches removing the now redundant
iio_sw_buffer_preenable calls.
* Lots of conversions to the new event registration methods.
* Another round of hmc5843 cleanups as that driver moves towards graduating
from staging.
* Make some SoC drivers buildable if COMPILE_TEST is used. Follow up fixes
for a few bits and bobs that revealed.
* Add explicit includes of linux/of.h to those drivers making us of linux/of.h
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.22 (GNU/Linux)
iQIcBAABAgAGBQJSYmsbAAoJEFSFNJnE9BaIuvsQAIxknxxAVBl8Jj8sqFJM/TJh
/iBP4c7HPsiZUFAyt59PONvwaY2iacTjWYx55mPsHpLXtVG4nsTj/E21lSPsp90D
YuXLmT8vU4kN3X1wJkiUmBYzO6mqHlBw8Z+dcLB4N4xOpHgvFTSuc12Gdmilbna2
APjAm513G6MiSEyG/RpNsKXGHFZBOCnvjs4hTQKg9QEzLvoqBZ/e3vUAsswMFLvP
eTTMRvgfNz2TSeOR1F5tNrMTnilAuBUZ8sCUw4HwtNN2KAnUNKtuGD174U00z7pH
qKCfZffm34Vb7niEZsVn2MhvbXwdUgWmEF1yqwApXTfnXsDTqWLakhMUHExIMozo
8jIewD30v6Daj+biPGxnmikRl9XfzgCN5nO11lx68rwur4q2KMYvSRdMVecipa6U
grSgXebFoQgdnj+2CN/0Z0pMqHeXpgMYzpG04o30/SjXgF4KRD6nDLZamJwwVHDj
Iivn5EyJeOt83BKSAtHm6tRqIbZ1abVwHoztxPDgl0nnuEtRv4VMGECOtLlGkHkx
lV2DdLd4UyahF3gPp6xvbnmhk6yWH4xMN0zwImSI4Lt7+ncRoZ6dy2i3HxrHNyu6
8zMKdZQDnMMoxcdqSxy5nXezf/x6e2MVReQiWLbSzpD1WU6OD0BrfGMe+3sFXSde
lsFgkAigdJ58t2vZ+gwb
=TXhl
-----END PGP SIGNATURE-----
Merge tag 'iio-for-3.12d' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
Fourth round of IIO new drivers, functionality and cleanups for the 3.13 cycle.
New Drivers
* cm36651 combined RGB light and proximity sensor.
Core improvements
* Some more fixes and cleanups related to buffers. These include the second
half of a series which went is as fixes. The basis for delaying until the
next merge window is that some are too invasive for this late in a cycle
and others only effect code paths current unused in the mainline tree.
In this case we have:
* protecting against concurrent userspace access
* fixing a memory leak if a device goes away
* avoiding always reallocating the buffer whether or not it has changed
(a bug fix, but one with no functional changes other than a small speed
improvement.)
* Add reference counting for buffers to ensure they hang around if open
from userspace or in kernel when the device is forcefully removed.
* Return -ENODEV for buffer access operations when the device has gone
away.
* Add proper locking for iio_update_buffers (currently we only have one
buffer per device in mainline, but an input bridge driver is under
development which would make this bug 'real'.)
* Wake up anyone waiting on a buffer if the device is unregistered. A
subsequent read will fail, notifying userspace that the device is no
longer there rather than having it wait possibly for ever.
* Move the iio_sw_preenable functionality into the core. This avoids drivers
having to 'know' about how the buffers are implemented and is called by
almost all drivers anyway. Those that don't call it are not harmed by it
being called.
* New registration approach for information (i.e. sysfs attributes) about
events. Much more generic and now similar to how the equivalent is
handled for channel information. The events infrastructure had been left
behind by other changes so this brings it back in line.
* Using the new events registration approach, add a hysterisis event_info
element and apply this to those drivers with this property.
* A little unitialized variable bug in the generic_buffer.c example.
* Factor out the code for freeing lists of IIO Device attributes to avoid
some repitition.
Driver cleanups
* At91 driver gains touch screen support and some related fixes.
* Follow up series of patches removing the now redundant
iio_sw_buffer_preenable calls.
* Lots of conversions to the new event registration methods.
* Another round of hmc5843 cleanups as that driver moves towards graduating
from staging.
* Make some SoC drivers buildable if COMPILE_TEST is used. Follow up fixes
for a few bits and bobs that revealed.
* Add explicit includes of linux/of.h to those drivers making us of linux/of.h
Pull btrfs fix from Chris Mason:
"Sage hit a deadlock with ceph on btrfs, and Josef tracked it down to a
regression in our initial rc1 pull. When doing nocow writes we were
sometimes starting a transaction with locks held"
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mason/linux-btrfs:
Btrfs: release path before starting transaction in can_nocow_extent
- intel_pstate fix for misbehavior after system resume if sysfs
attributes are set in a specific way before the corresponding
suspend from Dirk Brandewie.
- A recent intel_pstate fix has no effect if unsigned long is 32-bit,
so fix it up to cover that case as well.
- The s3c64xx cpufreq driver was not updated when the index field of
struct cpufreq_frequency_table was replaced with driver_data, so
update it now. From Charles Keepax.
- The Kconfig help text for ACPI_BUTTON still refers to /proc/acpi/event
that has been dropped recently, so modify it to remove that reference.
From Krzysztof Mazur.
- A Lan Tianyu's change adds a missing mutex unlock to an error code
path in acpi_resume_power_resources().
- Some code related to ACPI power resources, whose very purpose is
questionable to put it lightly, turns out to cause problems to
happen during testing on real systems, so remove it completely
(we may revisit that in the future if there's a compelling enough
reason). From Rafael J Wysocki and Aaron Lu.
/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.19 (GNU/Linux)
iQIcBAABCAAGBQJSYZQiAAoJEILEb/54YlRxed8QAJxDNJ4sHEzahsEFREZWwUy6
KN6yLRFs80aplbiCdNyYQnp5RZ0QqEVq0Vwkur/pxk5j00XJWTMknKvJhiAlIaHd
l1T1X0Oh3w4Z8h+0l49QaU0z5tHt+dAxzl4ArMlcQ3BQuKf5/8c+dIfNutkWpOWP
xHIDjEV+Y+8JCQoP92we7BbJpBRqzC3AOr05iH0wUN/i4dZzfqEca6KxTBPSXAcX
CbEBOXauG4BR4LyEQ2rlEt53FTp7XjZ9my1kKVH6LmtA+HiHeQmZMHTUf9dlaYAH
1n38ebeIHpskRYhu7nknto1S/mTVKxkzuSQ8TyKM+QOZz9x+WT/uiZjwbxINmxKk
fLi8TdMdv+WwALAqI36AjgfxdTtQ8Fhs/jSOoCY3KqoE4LMUInq2izWy8ALTQCPm
8PhM2WiYPFt6qSCqaKLfbbYH3ou6t2PQZihRfqpGEaTatNvwL2AYgl5QhOhs90EV
kYwZpfxodTNLnk4UfLGASjVEDRxgN7DUSrUvn0z7HmhbH/0YK3OVdLU0UQalAvfR
eUKYO+aWXzGsJO/ym3qfHkehumReCM62ykf295ApYnt134oqGDe3+Ajgx53WPj/P
ruIrfkmqDHCXjlVJ8f+UaZ/HXlDLcLrjlIVF1Dp0MKnl49pe+va4OmAxyImvTtFC
gciZiW+n5uowNojt8yye
=MV4Q
-----END PGP SIGNATURE-----
Merge tag 'pm+acpi-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm
Pull ACPI and power management fixes from Rafael Wysocki:
- intel_pstate fix for misbehavior after system resume if sysfs
attributes are set in a specific way before the corresponding suspend
from Dirk Brandewie.
- A recent intel_pstate fix has no effect if unsigned long is 32-bit,
so fix it up to cover that case as well.
- The s3c64xx cpufreq driver was not updated when the index field of
struct cpufreq_frequency_table was replaced with driver_data, so
update it now. From Charles Keepax.
- The Kconfig help text for ACPI_BUTTON still refers to
/proc/acpi/event that has been dropped recently, so modify it to
remove that reference. From Krzysztof Mazur.
- A Lan Tianyu's change adds a missing mutex unlock to an error code
path in acpi_resume_power_resources().
- Some code related to ACPI power resources, whose very purpose is
questionable to put it lightly, turns out to cause problems to happen
during testing on real systems, so remove it completely (we may
revisit that in the future if there's a compelling enough reason).
From Rafael J Wysocki and Aaron Lu.
* tag 'pm+acpi-3.12-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm:
ACPI / PM: Drop two functions that are not used any more
ATA / ACPI: remove power dependent device handling
cpufreq: s3c64xx: Rename index to driver_data
ACPI / power: Drop automaitc resume of power resource dependent devices
intel_pstate: Fix type mismatch warning
cpufreq / intel_pstate: Fix max_perf_pct on resume
ACPI: remove /proc/acpi/event from ACPI_BUTTON help
ACPI / power: Release resource_lock after acpi_power_get_state() return error
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Cc: Maxime Ripard <maxime.ripard@free-electrons.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
'of_match_ptr' is defined in linux/of.h. Include it explicitly to
avoid build breakage in the future.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We can't be holding tree locks while we try to start a transaction, we will
deadlock. Thanks,
Reported-by: Sage Weil <sage@inktank.com>
Signed-off-by: Josef Bacik <jbacik@fusionio.com>
Signed-off-by: Chris Mason <chris.mason@fusionio.com>
* acpi-fixes:
ACPI / PM: Drop two functions that are not used any more
ATA / ACPI: remove power dependent device handling
ACPI / power: Drop automaitc resume of power resource dependent devices
ACPI: remove /proc/acpi/event from ACPI_BUTTON help
ACPI / power: Release resource_lock after acpi_power_get_state() return error
Pull CIFS fixes from Steve French:
"Five small cifs fixes (includes fixes for: unmount hang, 2 security
related, symlink, large file writes)"
* 'for-linus' of git://git.samba.org/sfrench/cifs-2.6:
cifs: ntstatus_to_dos_map[] is not terminated
cifs: Allow LANMAN auth method for servers supporting unencapsulated authentication methods
cifs: Fix inability to write files >2GB to SMB2/3 shares
cifs: Avoid umount hangs with smb2 when server is unresponsive
do not treat non-symlink reparse points as valid symlinks
AT91 ADC hardware integrate touch screen support. So this patch add touch
screen support for at91 adc iio driver.
To enable touch screen support in adc, you need to add the dt parameters:
1. which type of touch are used? (4 or 5 wires), sample period time.
2. correct pressure detect threshold value.
In the meantime, since touch screen will use a interal period trigger of adc,
so it is conflict to other hardware triggers. Driver will disable the hardware
trigger support if touch screen is enabled.
This driver has been tested in AT91SAM9X5-EK and SAMA5D3x-EK.
Signed-off-by: Josh Wu <josh.wu@atmel.com>
Acked-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
CC: devicetree@vger.kernel.org
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
and be consistent with other setter functions in that first argument
is hmc5843_data
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
only continuous mode is supported for now; the driver could/should
be switched to single conversion mode
operating mode should be determined by the way IIO accesses the device
and not exposed explicitly
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
v3:
* use __be16 instead of s16
v2 (thanks to Jonathan Cameron):
* drop dynamic buffer allocation, buffer is in hmc5842_data
* grab timestamp near data acquisition
* restrict available scan masks (only read all axis)
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
v2:
* use __be16 instead of s16
Split out data ready/wait for read measurement
fix bug in case reading status register fails
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
and drop/inline helper functions _check_int_plus_micros() and
_show_int_plus_micros()
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
v3:
* rename _check_scale() to _get_scale_index()
v2:
* use SCALE instead of CALIBSCALE to control the range/gain
of measurements
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds device tree binding documentation for CM36651 proximity/light sensor.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds a new driver for Capella CM36651 proximity and RGB sensor.
Signed-off-by: Beomho Seo <beomho.seo@samsung.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The test in the spear_adc driver which checks whether the IRQ number returned
by platform_get_irq() has multiple problems. It accepts 0 even though this is
an invalid IRQ. It also rejects IRQ numbers that are larger or equal than
NR_IRQS. First of all drivers should never need to reference NR_IRQS and
secondly with CONFIG_SPARSE_IRQ NR_IRQS is not the upper limit, so the check
might reject valid IRQ numbers. This patch modifies the check to only test
against less or equal to 0.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Stefan Roese <sr@denx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The test in the lpc32xx_adc driver which checks whether the IRQ number returned
by platform_get_irq() has multiple problems. It accepts 0 even though this is an
invalid IRQ. It also rejects IRQ numbers that are larger or equal than NR_IRQS.
First of all drivers should never need to reference NR_IRQS and secondly with
CONFIG_SPARSE_IRQ NR_IRQS is not the upper limit, so the check might reject
valid IRQ numbers. This patch modifies the check to only test against less or
equal to 0.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Cc: Roland Stigge <stigge@antcom.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Removed the checkpatch warning of line over 80 chars
by breaking the long line into sensible chunks of 2 lines
to comply with coding style
Signed-off-by: Nandini Hanumanthagowda <nandu.hgowda@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
