The constants MAX_COMPLETIONS and MSG_QUEUE_SIZE control
the number of messages that can be outstanding to each client
before the system as a whole stalls. If the numbers are too
small then unnecessary thread switching will occur while
waiting for a (potentially low priority) client thread to
consume some data; badly written clients can even lead to
deadlock.
For services that carry many short messages, 16 messages can
represent a very small amount of data. Since the resources
are small - 16 bytes for a completion, 4 bytes for a message
pointer - increase the limits so they are unlikely to be hit
except in exceptional circumstances.
Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Phil Elwell [Tue, 17 Jan 2017 20:56:13 +0000 (20:56 +0000)]
staging: vchiq_arm: Service callbacks must not fail
Service callbacks are not allowed to return an error. The internal
callback that delivers events and messages to user tasks does not
enqueue them if the service is closing, but this is not an error
and should not be reported as such.
Signed-off-by: Phil Elwell <phil@raspberrypi.org> Signed-off-by: Stefan Wahren <stefan.wahren@i2se.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dummy codec register were initially added while populating dummy codec
mixer controls until module topology parser was available. Now, these
dummy registers are nowhere used and thus can be safely removed.
Since ASoC framework requires a valid callback for both read & write
register APIS, currently empty placeholders are kept to avoid panic.
Later, register mapping logic can be defined:
1. Assuming fixed number of maximum modules connected and register bits
corresponds to basic info of each module OR
2. With a logic to dynamically grow register_cache_size based on codec
modules added/removed.
Vaibhav Agarwal [Wed, 18 Jan 2017 17:21:51 +0000 (22:51 +0530)]
staging: greybus: audio: Initialize sig_bits before configuring hwparams
Uninitialized variable sig_bits was used while configuring stream params
for codec module. These params are used to configure PCM settings for
APBridgeA.
Usually, this is dependent on codec capability and thus populated via
codec dai_driver definition. In our case, it is fixed to 16 based on the
data format, container supported.
Vaibhav Agarwal [Wed, 18 Jan 2017 17:21:50 +0000 (22:51 +0530)]
staging: greybus: audio: Avoid less than zero check for le32 variable
mixer control->info call back function checks for -ve values to rebase
min and max values. However, le32 variable is used to fetch values from
GB module FW. Thus negative value checking is not required. Fix this!!
staging: rtl8188eu: fix type sign of len in rtw_get_bcn_info
len was declared unsigned int where we use an int
Fix sparse (-Wtypesign) issues:
drivers/staging/rtl8188eu/core/rtw_ieee80211.c:1081:88: warning: incorrect type in argument 3 (different signedness)
drivers/staging/rtl8188eu/core/rtw_ieee80211.c:1081:88: expected int *len
drivers/staging/rtl8188eu/core/rtw_ieee80211.c:1081:88: got unsigned int *<noident>
drivers/staging/rtl8188eu/core/rtw_ieee80211.c:1091:86: warning: incorrect type in argument 3 (different signedness)
drivers/staging/rtl8188eu/core/rtw_ieee80211.c:1091:86: expected int *len
drivers/staging/rtl8188eu/core/rtw_ieee80211.c:1091:86: got unsigned int *<noident>
Ian Abbott [Mon, 16 Jan 2017 14:12:26 +0000 (14:12 +0000)]
staging: comedi: ni_pcimio: Support more PXI cards
Add support for NI PXI-6220, PXI-6221, PXI-6229, PXI-6250, PXI-6254,
PXI-6259, PXIe-6259, PXI-6280, PXI-6284, and PXI-6289 boards, treating
them the same as the correspondingly numbered PCI and PCIe boards (apart
from having different Comedi board name strings). The same has
previously been done for other PXI boards supported by the driver.
The PCI device IDs for the newly supported boards come from the
"nixswv.inf" file in National Instrument's Windows drivers.
Also, sort `ni_pcimio_pci_table[]` by PCI device ID. It is mostly
sorted already, so only the entries for PXI-6251 and PXIe-6251 need
moving.
Signed-off-by: Ian Abbott <abbotti@mev.co.uk> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Merge tag 'iio-for-4.11a' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next
Jonathan writes:
First round of new device support, features and cleanups for IIO in the 4.11 cycle.
It's shaping to be another fairly busy cycle. Lots more on the way!
New device support
* ads7950
- new driver supporting ads7950, ads7951, ads7952, ads7953, ads7954,
ads7955, ads7956, ads7957, ads7958, ads7959, ads7960, and ads7961 ADCs.
* cm3605
- New driver for this light sensor and proximity sensor which is an
analog part with some additional digital controls.
* hx711
- New driver.
Core new stuff
* Gravity sensor type. This is a processed datastream in which the device
will try to work out which way is down.
* Split the buffer.h file into two parts. One provides the interface to 'use'
a buffer, the second provides the internals of the buffer functionality as
needed by implementations of buffers.
- Move documentation inline so as to allow use of private: tag when
generating documentation.
- Add some utility functions for the few things that are directly done
with the buffers.
- Stop exporting functions that no-one uses outside of the core code.
- Push docs down by the code in the c file where they should have always
been.
- Fix typo in kernel-doc for buffer.
- push down some includes that were previously happening implicitly.
- stop enabling the timestamp of the dummy device.
Features and cleanups
* ad5592r
- ACPI support
* ad5593r
-ACPI support.
* ad5933
- Fix a false comment about size of a particular register.
* ad7150
- replace S_IRUGO | S_IWUSR with 0644. I'm not that keen on these patches
in general, but as it was nicely presented I took this one anyway. As a
general rule will only take these as part of a larger driver cleanup.
- don't eat an error but rather reutnr it in the write_event_config callback.
* ad7606
- replace non standard range attibute with _scale
* ade7753
- use usleep_range for short sleeps
* ade7754
- use usleep_range for short sleeps
* ade7758
- use usleep_range for short sleeps
* ade7759
- use usleep_range for short sleeps
* ade7854
- use usleep_range for short sleeps
* adis16201
- fix description
* adis16203
- fix description
- fix copyright year
* adis16209
- fix description
* adt7316
- Add braces to arms of if else statement (for consistency)
- Alignment fixes.
* axp288
- Fix up an issue with accidental overwrites of data.
* bmi160
- add deivce tables for i2c and spi to support correctly identifying the
full dt name (including manufacturer).
- device tree binding.
* bmp280
- use usleep_range for short sleeps.
* cm3232
- return error from cm3232_reg_init rather than eating it if the last write
fails.
* dummy driver
- remove a semicolor found at end of a function defintition.
* exynos-adc
- use usleep_range for short sleeps.
* hid-sensor (accel)
- Add timestamp support. The hardware can provide timestamps so lets support
them. If not fall back to timestamps estimated in kernel.
* hid-sensor (light)
- Add a duplicate ID for the light channels so as to keep existing interface
whilst also using the more standard IIO interface.
* hts221
- acpi probing
* imx25-gcq
- Add a macro call to allow this driver to be automatically loaded.
* isl29028
- reorganise code to avoid deep nesting of if statements.
- move chip test and default regs into a function suitable or sharing with
power management code.
- tidy up some code alignment.
* lidar-lite-v3
- introduce compatible strings that make it clear Garmin have consideral
friends.
* mma8452
- avoid returning signed value when unsigned is appropriate
* spmi-vadc
- Update function for generic voltage conversion to take into account that
different channels on this device should be handled differently.
- Rework code to allow per channel voltage scaling and support the standard
options for this hardware.
- Fixup three minor issues with the above patches for this part. These all
effect test builds rather than the native builds for the part, but good to
clean them up anyway.
* st_sensors
- support device matching from the ACPI DST tables.
- acpi based probing for accelerometers
- acpi based probing for pressure sensors
- Allow pressure sensors to read negative values.
- Export sampling frequency for lps25h and lps331ap.
- Add support for the old DT bindings from the period when these deivces
were often supported through windows.
Shyam Saini [Sun, 15 Jan 2017 12:51:46 +0000 (18:21 +0530)]
staging: rtl8192e: rtl8192e: Remove NULL test before vfree
vfree frees the virtually continuous block of memory beginning at addr.
If addr is NULL, no operation is performed. So, NULL test is not needed
before vfree.
Arnd Bergmann [Wed, 11 Jan 2017 14:53:08 +0000 (15:53 +0100)]
staging: rtl: fix possible NULL pointer dereference
gcc-7 detects that wlanhdr_to_ethhdr() in two drivers calls memcpy() with
a destination argument that an earlier function call may have set to NULL:
staging/rtl8188eu/core/rtw_recv.c: In function 'wlanhdr_to_ethhdr':
staging/rtl8188eu/core/rtw_recv.c:1318:2: warning: argument 1 null where non-null expected [-Wnonnull]
staging/rtl8712/rtl871x_recv.c: In function 'r8712_wlanhdr_to_ethhdr':
staging/rtl8712/rtl871x_recv.c:649:2: warning: argument 1 null where non-null expected [-Wnonnull]
I'm fixing this by adding a NULL pointer check and returning failure
from the function, which is hopefully already handled properly.
This seems to date back to when the drivers were originally added,
so backporting the fix to stable seems appropriate. There are other
related realtek drivers in the kernel, but none of them contain a
function with a similar name or produce this warning.
Cc: stable@vger.kernel.org Fixes: 1cc18a22b96b ("staging: r8188eu: Add files for new driver - part 5") Fixes: 2865d42c78a9 ("staging: r8712u: Add the new driver to the mainline kernel") Signed-off-by: Arnd Bergmann <arnd@arndb.de> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Fix checkpatch warnings for parameter type unsigned in greybus.
Note that this patch does not fix all checkpatch warnings for the
affected files.
Signed-off-by: Christian Bewermeyer <christian.bewermeyer@fau.de> Signed-off-by: Roman Sommer <roman.sommer@fau.de> Reviewed-by: Johan Hovold <johan@kernel.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Dan Carpenter [Sun, 15 Jan 2017 08:14:07 +0000 (11:14 +0300)]
staging: lustre: ptlrpc: silence a shift wrapping warning
"svcpt->scp_hist_seq" is a u64 so static checkers complain that 1U
should be 1ULL. I looked at REQS_SEQ_SHIFT() a little and it seems to
be capped by the number of CPUs online and the amount of memory, but I
think it could go above 32 possibly.
iio:adc:qcom-spmi-vadc: use div64_s64 instead of direct 64 bit division.
Another one of these that we missed previously which prevents test builds
of this driver on 32 bit platforms as it gives an undefined __divdi3 warning.
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Jonathan Cameron [Fri, 30 Dec 2016 18:25:49 +0000 (18:25 +0000)]
iio:adc:qcom-spmi-vadc : fix undefined __divdi3
A simple do_div call works here as all the signed 64 bit is
actually small and unsigned at this point, and the numerator is
u32.
Introduce a temporary u64 variable to avoid type comparison warnings
on some architectures.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reported-by: kbuild test robot <fengguang.wu@intel.com> Cc: Rama Krishna Phani A <rphani@codeaurora.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
Hans de Goede [Wed, 14 Dec 2016 13:55:25 +0000 (14:55 +0100)]
iio: adc: axp288: Drop bogus AXP288_ADC_TS_PIN_CTRL register modifications
For some reason the axp288_adc driver was modifying the
AXP288_ADC_TS_PIN_CTRL register, changing bits 0-1 depending on
whether the GP_ADC channel or another channel was written.
These bits control when a bias current is send to the TS_PIN, the
GP_ADC has its own pin and a separate bit in another register to
control the bias current.
Not only does changing when to enable the TS_PIN bias current
(always or only when sampling) when reading the GP_ADC make no sense
at all, the code is modifying these bits is writing the entire register,
assuming that all the other bits have their default value.
So if the firmware has configured a different bias-current for either
pin, then that change gets clobbered by the write, likewise if the
firmware has set bit 2 to indicate that the battery has no thermal sensor,
this will get clobbered by the write.
This commit fixes all this, by simply removing all writes to the
AXP288_ADC_TS_PIN_CTRL register, they are not needed to read the
GP_ADC pin, and can actually be harmful.
Signed-off-by: Hans de Goede <hdegoede@redhat.com> Acked-by: Chen-Yu Tsai <wens@csie.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
If the driver is built as a module, autoload won't work because the module
alias information is not filled. So user-space can't match the registered
device with the corresponding module.
Export the module alias information using the MODULE_DEVICE_TABLE() macro.
Before this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
$
After this patch:
$ modinfo drivers/iio/adc/fsl-imx25-gcq.ko | grep alias
alias: of:N*T*Cfsl,imx25-gcqC*
alias: of:N*T*Cfsl,imx25-gcq
Signed-off-by: Javier Martinez Canillas <javier@osg.samsung.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
iio:buffer.h - split into buffer.h and buffer_impl.h
buffer.h supplies everything needed for devices using buffers.
buffer_impl.h supplies access to the internals as needed to write
a buffer implementation.
This was really motivated by the mess that turned up in the
kernel-doc documentation pulled in by the new sphinx docs.
It made it clear that our logical separations in headers were
generally terrible. The buffer case was easy to sort out without
greatly effecting drivers so here it is.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
It's bad practice and only done in this fake driver + it breaks my
attempt to take struct buffer opaque. Not worth an access function
as it shouldn't be done anyway.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
iio:buffer: Push implementation of iio_device_attach_buffer into .c file
This is a precursor to the splitting of buffer.h into parts relevant
to buffer implementation vs those for devices using buffers.
struct buffer is about to become opaque as far as the header is
concerned.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
iio:buffer.h include pushdown into buffer implementations
These were only getting access to the internals of struct iio_dev via
the include of iio.h within buffer.h. This should always have been
explicitly included by the buffer implementations themselves.
Signed-off-by: Jonathan Cameron <jic23@kernel.org> Reviewed-by: Lars-Peter Clausen <lars@metafoo.de>
projects / mirror_ubuntu-eoan-kernel.git / log