- 07 Sep, 2013 14 commits
-
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_iio_device_alloc makes code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_iio_device_alloc makes the code simple. While at it also fixed an uninitialized return with -EINVAL. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: J. August Brenner <jbrenner@taosinc.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. This also fixes an error in return type during clk_get failure. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Cc: Roland Stigge <stigge@antcom.de> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_iio_device_alloc makes code simpler. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
Sachin Kamat authored
devm_* APIs are device managed and make code simpler. The memory leak was a lack of freeing the iio_dev structure in the remove function. Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
- 31 Aug, 2013 1 commit
-
-
Peter Meerwald authored
Signed-off-by: Peter Meerwald <pmeerw@pmeerw.net> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-
- 30 Aug, 2013 23 commits
-
-
Matthijs Kooijman authored
Some of the defaults were missing or unclear. In particular, I suspect the defaults were documented assuming there were still module parameters and taking the default module parameters into account. Now, the defaults are the values that will get chosen when the params passed to dwc2_hcd_init are all -1. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
The HWCFG4 register stores the supported utmi width values (8, 16 or both). This commit reads that value and validates the configured value against that. If no (valid) value is given, the parameter defaulted to 8 bits previously. However, the documentation for dwc2_core_params_struct suggests that the default should have been 16. Also, the pci bindings explicitely set the value to 16, so this commit changes the default to 16 bits (if supported, 8 bits otherwise). With the default changed, the value set in pci.c is changed to -1 to make it autodetected as well. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
Before, the hwcfg registers were read at device init time, but interpreted at various parts in the code. This commit unpacks the hwcfg register values into a struct with properly labeled variables at init time, which makes all the other code using these values more consise and easier to read. Some values that were previously stored in the hsotg struct are now moved into this new struct as well. In addition to the hwcfg registers, the contents of some fifo size registers are also unpacked. The hwcfg registers are read-only, so they can be safely stored. The fifo size registers are read-write registers, but their power-on values are significant: they give the maximum depth of the fifo they describe. This commit mostly moves code, but also attempts to simplify some expressions from (val >> shift) & (mask >> shift) to (val & mask) >> shift. Finally, all of the parameters read from the hardware are debug printed after unpacking them, so a bunch of debug prints can be removed from other places. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
Bits 16-31 are reserved, so the old code just reads the whole register to get bits 0-15, assuming the reserved bits would be 0 (which seems true on current hardware, but who knows...). This commit properly masks out the reserved bits when reading and doesn't touch the reserved bits while writing. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
For calculating FIFO offsets, the sizes of preceding fifos need to be known. For filling the GDFIFOCFG register, these fifo sizes were read from hardware registers. However, these values were written to these registers just a few lines before, so we can just use the values written instead. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
For some reason, the value of the HPTXFSIZ register was built in the ptxfsiz variable, while there was also a hptxfsiz variable availble. Better just use that and remove the (now unused) ptxfsiz variable. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
The value of the hcchar register is built from individual values by shifting and masking. Before, the debug output extracted the individual values out of the complete hcchar register again by doing the reverse. This commit makes the debug output use the original values instead. One debug message got removed, since it would always print a fixed value of zero. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
This line extracted the available queue space without properly shifting it. Since the code only cared wether it was zero or not, it worked as expected without the shift, but adding shift makes the code cleaner. While we're here, store the result in a helper variable that was already declared to increase readability a bit more. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
This commit changes expressions from (val >> shift) & (mask >> shift) to (val & mask) >> shift. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
This (read-only) register was read twice, storing it for later use the second time. Now it is only read once, storing it right away. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
Various register fields wider than one bit have constants defined for their value. Previously, these registers would define the values as they appear in the register, so shifted to the right to the position the value appears in the register. This commit changes those constants to their natural values (e.g, 0, 1, 2, etc.), as they are after shifting the register value to the right. This also changes all relevant code to shift the values before comparing them with constants. This has the advantage that the values can be stored in smaller variables (now they always require a u32) and makes the handling of these values more consistent with other register fields that represent natural numbers instead of enumerations (e.g., number of host channels). Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
Previously, the max_packet_count could be set to 1 << x, where x is the number of bits available (width + 4 in the code). Since 1 << x requires x + 1 bits to represent, this will not work. The real maximum value is (1 << x) - 1. This value is already used the default when the set value is invalid, but the upper limit for the set value was off-by-one. This change makes the check the same as the one for max_transfer_size, which was already correct. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Matthijs Kooijman authored
A generic set of FIFOSIZE_* constants is defined which applies to all fifo size and offset registers. It is already used for both the GNPTXFSIZ and HPTXFSIZ registers, but it applies to DPTXFSIZN as well. Some of these also had specific constants defined. This patch removes the specific constants and documents to use the generic constants. Note that the removed constants weren't actually used. Instead, most of the related code uses hardcoded masks and shifts. But given that subsequent patches will be moving that code around and introducing the constants in the process, this patch leaves those untouched. Also note that the GRXFSIZ register also contains a fifo size, but there is no corresponding start address register (it is always the first fifo in memory), the layout of the GRXFSIZ register is different and cannot use the same constants. Signed-off-by: Matthijs Kooijman <matthijs@stdin.nl> Acked-by: Paul Zimmerman <paulz@synopsys.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Paul McQuade authored
__Function__ gets renamed with __func__ Signed-Off-By: Paul McQuade <paulmcquad@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
navin patidar authored
many of the macros defined in Version.h are not being used, so we can remove the file. Signed-off-by: navin patidar <navinp@cdac.in> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
"keyid" is used as an offset into the ->dot11DefKey[] array. The array has 4 elements. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
There is a copy and paste bug here so we copy 4 bytes instead of 3. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
Obviously it's impossible for ->KeyLength to be both 5 and 13. I assume that && was intended here. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Dan Carpenter authored
These should be "<" instead of "<=". Also we can use the ARRAY_SIZE() macro. Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Shaun Laing authored
The result from crystalhd_get_sgle_paddr and crystalhd_get_sgle_len are later used in calculations, so the result should be in CPU byte ordering. Signed-off-by: Shaun Laing <shaun@xresource.ca> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Larry Finger authored
The 0-DAY kernel build testing backend reports the following compiler warnings not shown on my compiler version/options: drivers/staging/rtl8188eu/os_dep/ioctl_linux.c: In function 'rtw_mp_efuse_get': >> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:5836:65: warning: iteration 16u invokes undefined behavior [-Waggressive-loop-optimizations] sprintf(extra, "%s%02X ", extra, pEfuseHal->fakeEfuseInitMap[i+j]); ^ drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:5830:3: note: containing loop for (i = 0; i < EFUSE_MAP_SIZE; i += 16) { ^ >> drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:6042:69: warning: iteration 16u invokes undefined behavior [-Waggressive-loop-optimizations] sprintf(extra, "%s %02X", extra, pEfuseHal->fakeEfuseModifiedMap[i+j]); ^ drivers/staging/rtl8188eu/os_dep/ioctl_linux.c:6036:3: note: containing loop for (i = 0; i < EFUSE_MAP_SIZE; i += 16) { ^ The problem is due to improper settings for some of the EFUSE_XXX defines such that EFUSE_MAP_SIZE was larger than the sizes of the marked arrays. Thanks to Fengguang Wu for helping me understand the root cause. Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Larry Finger <Larry.Finger@lwfinger.net> Cc: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Geert Uytterhoeven authored
drivers/staging/dgap/dgap_driver.c: In function ‘dgap_cleanup_module’: drivers/staging/dgap/dgap_driver.c:423: error: implicit declaration of function ‘kfree’ drivers/staging/dgap/dgap_driver.c: In function ‘dgap_driver_kzmalloc’: drivers/staging/dgap/dgap_driver.c:940: error: implicit declaration of function ‘kmalloc’ drivers/staging/dgap/dgap_driver.c:940: warning: initialization makes pointer from integer without a cast Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Lidza Louina authored
This patchs adds a TODO for the driver. Signed-off-by: Lidza Louina <lidza.louina@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
- 29 Aug, 2013 2 commits
-
-
Greg Kroah-Hartman authored
Merge tag 'iio-for-3.12c' of git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-next Jonathan writes: Third set of new drivers, cleanups and features for IIO in the 3.12 cycle. New drivers 1) Bosh BMA180 accelerometer + a new sysfs abi element, power_mode to allow for device that trade off accuracy and power usage. Cleanups 1) Another lot of devm_iio_device_alloc patches 2) An code ordering bug in the twl6030 driver introduced earlier in this cycle. New features 1) at91 adc driver rework to support a wider range of parts and drop the necessity for some of the current device tree elements. This is a precursor to introducing input support which is still under review.
-
Josh Wu authored
For at91 boards, there are different IPs for adc. Different IPs has different STARTUP & PRESCAL mask in ADC_MR. Signed-off-by: Josh Wu <josh.wu@atmel.com> Acked-by: Maxime Ripard <maxime.ripard@free-electrons.com> Signed-off-by: Jonathan Cameron <jic23@kernel.org>
-