Note this is not a bug due to the fact the region cannot be reached without the sanity check passing. The autobuilder reported it as missaligned code which is kind of true as well.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Cc: Roberta Dobrescu <roberta.dobrescu@gmail.com>
Clearly the intent was to error if the value was not 0 or 1.
As implemented we have (A != 0 || A != 1) which is always true
as A is never both 0 and 1 at the same time.
As the autobuilder suggested, && makes more sense for this error
check.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Acked-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Cc: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch refactors the isl29018 driver code in order to use standard
sysfs attributes for scale and integration time.
ISL29018 light sensor uses four ranges and four ADC's resolutions
which influence the calculated lux. Adc resolution is strongly
connected to integration time and range should be controlled by scale.
This patch introduces the usage of integration time and scale instead
of adc resolution and range.
Signed-off-by: Roberta Dobrescu <roberta.dobrescu@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch renames lux_scale to calibscale and lux_uscale to
ucalibscale.
This is done in order to avoid confusion since these parameters are
used for hardware applied calibration.
Signed-off-by: Roberta Dobrescu <roberta.dobrescu@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch removes non-standard sysfs attributes range, range_available,
adc_resolution and adc_resolution_available. It also removes the
corresponding show and store functions.
This is in preparation for using standard IIO attributes in order to move
the code out of staging.
Signed-off-by: Roberta Dobrescu <roberta.dobrescu@gmail.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Initial value of gpio bitnum is set to -1, but
the variable is declared as unsigned.
Use a positive invalid value for initial gpio
bitnum.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Suggested-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add mma9553_ prefix to all local functions/declarations.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Suggested-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use GENMASK instead of BIT or direct value to
define a mask.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Suggested-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use "GPIO" instead of "gpio" and "ACPI" instead of "acpi".
Includes a couple of small style fixes in comments
(missing full stop, whitespace, paranthesis).
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Suggested-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Use return 0 instead of return ret to mark
clearly the success return path.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Suggested-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
When configuring gpio, we need to read initial values for activity and
step count. This function may fail due to i2c read errors.
Check the error code returned by mma9553_read_activity_stepcnt
and return the appropriate error in gpio config function.
Signed-off-by: Irina Tirdea <irina.tirdea@intel.com>
Reported-by: Hartmut Knaack <knaack.h@gmx.de>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added support for Liteon 301 Ambient light sensor. Since
LTR-301 and LTR-501 are register compatible(and even have same
part id), LTR-501 driver has been extended to support both
devices. LTR-501 is similar to LTR-301 in ALS sensing, But the
only difference is, LTR-501 also supports proximity sensing.
LTR-501 - ALS + Proximity combo
LTR-301 - ALS sensor.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This device is register compatible with LTR501, with a minor difference for
ALS control register as showed below:
ALS Control register for LTR501:
7 6 5 4 3 2 1 0
+------+------+------+------+------+------+------+------+
| | | | |
| Reserved | Gain | SW | ALS Mode |
| | | Reset| |
+------+------+------+------+------+------+------+------+
ALS Control register for LTR559:
7 6 5 4 3 2 1 0
+------+------+------+------+------+------+------+------+
| | | | |
| Reserved | Gain | SW | ALS |
| | | Reset| Mode |
+------+------+------+------+------+------+------+------+
We handle this difference by introducing ltr501_chip_info.
Datasheet for LTR559 is at:
http://optoelectronics.liteon.com/upload/download/DS86-2013-0003/S_110_LTR-559ALS-01_DS_V1.pdf
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added ACPI enumeration support for LTR501 chip.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added rate control support for ALS and proximity
threshold interrupts.Also, Added support to modify
and read ALS & proximity sensor sampling frequency.
LTR-501 supports interrupt rate control using persistence
register settings. Writing <n> to persistence register
would generate interrupt only if there are <n> consecutive
data values outside the threshold range.
Since we don't have any existing ABI's to directly
control the persistence register count, we have implemented
the rate control using IIO_EV_INFO_PERIOD. _period event
attribute represents the amount of time in seconds an
event should be true for the device to generate the
interrupt. So using _period value and device frequency,
persistence count is calculated in driver using following
logic.
count = period / measurement_rate
If the given period is not a multiple of measurement rate then
we round up the value to next multiple.
This patch also handles change to persistence count whenever
there is change in frequency.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds interrupt support for Liteon 501 chip.
Interrupt will be generated whenever ALS or proximity
data exceeds values given in upper and lower threshold
register settings.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added support to modify and read ALS integration time.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
If a GPIO reset pin is listed in ACPI or Device Tree, use it to reset
the device on initialization.
Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In the interest of lowering power usage, we only activate the proximity
channels and interrupts that we are currently using.
For raw reads, we activate the corresponding channel and the data ready
interrupt and wait for the interrupt to trigger. If no interrupt is
available, we wait for the documented scan period, as specified in the
datasheet.
The following types of usage patterns may overlap:
* raw proximity reads (need a single data ready interrupt)
* trigger usage (needs data ready interrupts as long as active)
* proximity events (need near/far interrupts)
* triggered buffer reads (don't need any interrupts, but are usually
coupled with our own trigger.
To mitigate all possible patterns, we implement usage counting for all
the resources used: data ready interrupts, near/far interrupts and
individual channels.
The device enters sleep mode as documented in the data sheet when its
buffer, trigger and events are disabled, and no raw reads are currently
running.
Because of this new usage pattern, it is important that we give the
device a chance to perform an initial compensation for all its channels
at probe time.
Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Fix a typo triggering a duplicate const warning on some compilers.
Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Added regmap support. It will be useful to handle
bitwise updates to als & ps control registers.
Signed-off-by: Kuppuswamy Sathyanarayanan <sathyanarayanan.kuppuswamy@linux.intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This makes ltr501 code consistent with the coding style adopted
for the new drivers added to IIO.
We prepare the path for adding support for LTR559 chip.
Reported by checkpatch.pl
Signed-off-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Refactor DT parsing into a separate function from probe() to
help addition of more DT parameters later.
No functional changes.
Signed-off-by: Vignesh R <vigneshr@ti.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The device uses the MSB of the returned temperature value as an error
flag. Return a read error when this bit is set.
Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Add support for system sleep and runtime power management.
To wake up the device, the SDA line should be held low for at least 33ms
while SCL is high. As this is not possible using the i2c API (and not
supported by all i2c adapters), a GPIO connected to the SDA line is
needed. The GPIO is named "wakeup" and can be specified in a device
tree with the "wakeup-gpios" binding.
If the wake-up GPIO is not given, disable power management for the
device. Entering sleep requires an SMBus byte access, hence power
management is also disabled if byte access is not supported by the
adapter.
Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
The mapping from the 16-bit EEPROM value to the decimal 0-1 range is
approximate. A special case ensures 0xFFFF shows as 1.0 instead of
0.999998565.
Writing to EEPROM requires an explicit erase by writing zero. In
addition, it takes 20ms for the erase/write to complete. During this
time no EEPROM register should be accessed. Therefore, two msleep()s
are added to the write function and a mutex protects against concurrent
access.
Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Also introduce "melexis" as a vendor prefix for device tree bindings.
Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Contact-less IR temperature sensors measure the temperature of an object
by using its thermal radiation. Surfaces with different emissivity
ratios emit different amounts of energy at the same temperature.
IIO_CHAN_INFO_CALIBEMISSIVITY allows the user to inform the sensor of the
emissivity of the object in front of it, in order to effectively measure
its temperature.
A device providing such setting is Melexis's MLX90614:
http://melexis.com/Assets/IR-sensor-thermometer-MLX90614-Datasheet-5152.aspx.
Signed-off-by: Vianney le Clément de Saint-Marcq <vianney.leclement@essensium.com>
Cc: Arnout Vandecappelle (Essensium/Mind) <arnout@mind.be>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
In its present state, the driver mandates that its buffer only be
triggered by one of the device's own triggers (data ready or any
motion). This is not always desirable, for example because the
interrupt pins may not be wired in.
Patch the driver to be able to accept using an external trigger, such as
one based on hrtimer. When using such a trigger, we need to ensure that
the device is powered on when the buffer is started. We do that by
setting setup_ops for the buffer.
Signed-off-by: Vlad Dogaru <vlad.dogaru@intel.com>
Reviewed-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
This patch adds targets for building and cleaning iio tools to tools/Makefile.
To build iio tools from the toplevel kernel directory one should call:
$ make -C tools iio
and for cleaning it
$ make -C tools iio_clean
Signed-off-by: Roberta Dobrescu <roberta.dobrescu@gmail.com>
Reviewed-by: Daniel Baluta <daniel.baluta@intel.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
We want those fixes (iio primarily) into the -next branch to help with
merge and testing issues.
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Pull networking fixes from David Miller:
1) In TCP, don't register an FRTO for cumulatively ACK'd data that was
previously SACK'd, from Neal Cardwell.
2) Need to hold RNL mutex in ipv4 multicast code namespace cleanup,
from Cong WANG.
3) Similarly we have to hold RNL mutex for fib_rules_unregister(), also
from Cong WANG.
4) Revert and rework netns nsid allocation fix, from Nicolas Dichtel.
5) When we encapsulate for a tunnel device, skb->sk still points to the
user socket. So this leads to cases where we retraverse the
ipv4/ipv6 output path with skb->sk being of some other address
family (f.e. AF_PACKET). This can cause things to crash since the
ipv4 output path is dereferencing an AF_PACKET socket as if it were
an ipv4 one.
The short term fix for 'net' and -stable is to elide these socket
checks once we've entered an encapsulation sequence by testing
xmit_recursion.
Longer term we have a better solution wherein we pass the tunnel's
socket down through the output paths, but that is way too invasive
for 'net' and -stable.
From Hannes Frederic Sowa.
6) l2tp_init() failure path forgets to unregister per-net ops, from
Cong WANG.
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net:
net/mlx4_core: Fix error message deprecation for ConnectX-2 cards
net: dsa: fix filling routing table from OF description
l2tp: unregister l2tp_net_ops on failure path
mvneta: dont call mvneta_adjust_link() manually
ipv6: protect skb->sk accesses from recursive dereference inside the stack
netns: don't allocate an id for dead netns
Revert "netns: don't clear nsid too early on removal"
ip6mr: call del_timer_sync() in ip6mr_free_table()
net: move fib_rules_unregister() under rtnl lock
ipv4: take rtnl_lock and mark mrt table as freed on namespace cleanup
tcp: fix FRTO undo on cumulative ACK of SACKed range
xen-netfront: transmit fully GSO-sized packets
Commit 1daa4303b4 ("net/mlx4_core: Deprecate error message at
ConnectX-2 cards startup to debug") did the deprecation only for port 1
of the card. Need to deprecate for port 2 as well.
Fixes: 1daa4303b4 ("net/mlx4_core: Deprecate error message at ConnectX-2 cards startup to debug")
Signed-off-by: Jack Morgenstein <jackm@dev.mellanox.co.il>
Signed-off-by: Amir Vadai <amirv@mellanox.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
According to description in 'include/net/dsa.h', in cascade switches
configurations where there are more than one interconnected devices,
'rtable' array in 'dsa_chip_data' structure is used to indicate which
port on this switch should be used to send packets to that are destined
for corresponding switch.
However, dsa_of_setup_routing_table() fills 'rtable' with port numbers
of the _target_ switch, but not current one.
This commit removes redundant devicetree parsing and adds needed port
number as a function argument. So dsa_of_setup_routing_table() now just
looks for target switch number by parsing parent of 'link' device node.
To remove possible misunderstandings with the way of determining target
switch number, a corresponding comment was added to the source code and
to the DSA device tree bindings documentation file.
This was tested on a custom board with two Marvell 88E6095 switches with
following corresponding routing tables: { -1, 10 } and { 8, -1 }.
Signed-off-by: Pavel Nakonechny <pavel.nakonechny@skitlab.ru>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Reviewed-by: Florian Fainelli <f.fainelli@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Pull input fixes from Dmitry Torokhov:
"Updates for the input subsystem - two more tweaks for ALPS driver to
work out kinks after splitting the touchpad, trackstick, and potential
external PS/2 mouse into separate input devices.
Changes to support ALPS SS4 devices (protocol V8) will be coming in
4.1..."
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input:
Input: alps - document stick behavior for protocol V2
Input: alps - report V2 Dualpoint Stick events via the right evdev node
Input: alps - report interleaved bare PS/2 packets via dev3
mvneta_adjust_link() is a callback for of_phy_connect() and should
not be called directly. The result of calling it directly is as below:
Signed-off-by: David S. Miller <davem@davemloft.net>
We should not consult skb->sk for output decisions in xmit recursion
levels > 0 in the stack. Otherwise local socket settings could influence
the result of e.g. tunnel encapsulation process.
ipv6 does not conform with this in three places:
1) ip6_fragment: we do consult ipv6_npinfo for frag_size
2) sk_mc_loop in ipv6 uses skb->sk and checks if we should
loop the packet back to the local socket
3) ip6_skb_dst_mtu could query the settings from the user socket and
force a wrong MTU
Furthermore:
In sk_mc_loop we could potentially land in WARN_ON(1) if we use a
PF_PACKET socket ontop of an IPv6-backed vxlan device.
Reuse xmit_recursion as we are currently only interested in protecting
tunnel devices.
Cc: Jiri Pirko <jiri@resnulli.us>
Signed-off-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
Document that protocol V2 uses standard (bare) PS/2 mouse packets for the
DualPoint stick.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Acked-By: Pali Rohár <pali.rohar@gmail.com>
Signed-off-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
