- 01 Mar, 2012 3 commits
-
-
Larry Finger authored
In commit c6dc001f "staging: r8712u: Merging Realtek's latest (v2.6.6). Various fixes", the returned qual.qual member of the iw_statistics struct was changed. For strong signals, this change made no difference; however for medium and weak signals it results in a low signal that shows considerable fluctuation, When using wicd for a medium-strength AP, the value reported in the status line is reduced from 100% to 60% by this bug. This problem is reported in https://bugzilla.kernel.org/show_bug.cgi?id=42826. Reported-and-tested-by:
Robert Crawford <wrc1944@gmail.com> Signed-off-by:
Larry Finger <Larry.Finger@lwfinger.net> Cc: Stable <stable@vger.kernel.org> Signed-off-by:
Greg Kroah-Hartman <gregkh@linuxfoundation.org>
-
Larry Finger authored
In commit 8c213fa "staging: r8712u: Use asynchronous firmware loading", the command to release the firmware was placed in the wrong routine. In combination with the bug introduced in commit a5ee6529 "staging: r8712u: Interface-state not fully tracked", the driver attempts to upload firmware that had already been released. This bug is the source of one of the problems in https://bugs.archlinux.org/task/27996#comment89833. Tested-by:
Alberto Lago Ballesteros <saniukeokusainaya@gmail.com> Tested-by:
Adrian <agib@gmx.de> Signed-off-by:
-
Larry Finger authored
In commit a5ee6529 "staging: r8712u: Interface-state not fully tracked", the private boolean "bup" was set false when the interface was brought down, as that seemed appropriate. This change has not caused any problems when using NetworkManager or manual control of the device; however, when wicd control is used, there is a locking problem in wpa_supplicant, as shown in https://bugzilla.kernel.org/show_bug.cgi?id=42818. This fix reverts the only code change in commit a5ee6529. My analysis is that "bup" is badly named. In its present form, it seems to indicate the up/down state of the device, but its usage is more consistent with an initialized/uninitialized state. That problem will be addressed in a later patch. Note: Commit 8c213fa, which introdued asynchronous firmware loading for this driver, exposed this bug to a greater extent. That bug is addressed in the next patch in this series. This bug is also responsible for the bug in https://bugzilla.kernel.org/show_bug.cgi?id=42815. and this bug is also part of the problems discussed at https://bugs.archlinux.org/task/27996#comment89950. Tested-by:
-
- 29 Feb, 2012 13 commits
-
-
Dan Carpenter authored
In commit 1ca1a92c "Staging: wlan-ng: memsetting the wrong amount of data" I changed the code so we didn't memset() past the end of the msg1.bssid.data[] array. Walter Harms noticed that it was weird that we were setting the len to 6 when there were 7 elements in the array. Pavel Roskin pointed out that the intent of the code was actually to memset() msg1.bssid.data.data[] which is a 6 character array. Reported-by:
Walter Harms <wharms@bfs.de> Reported-by:
Pavel Roskin <proski@gnu.org> Signed-off-by:
Dan Carpenter <dan.carpenter@oracle.com> Signed-off-by:
-
Jorgyano Vieira authored
The header bc_dts_types is not used, so we can remove it. Signed-off-by:
Jorgyano Vieira <jorgyano@gmail.com> Signed-off-by:
-
Jorgyano Vieira authored
This patch replaces the local includes with the global header. So the the crystalhd.h will be the only header included by the other files. Signed-off-by:
-
Jorgyano Vieira authored
In the crystalhd_cmds.h there was a struct dependence bug: the struct crystalhd_adp (which is declared on crystalhd_lnx.h) is used on the crystalhd_cmd struct, however the crystalhd_lnx.h is never included on crystalhd_cmds.h at all. Including the crystalhd_lnx.h on crystalhd_cmds.h breaks the build, many dependencies error occurrs, most of the type "error: 'struct bar' has no member named 'foo'", so I decided to reorganize the headers by adding a global header. The gobal header crystalhd.h includes all the local headers. The idea is that the crystalhd header will be the only included by the others files, this will avoid the mess of many #include levels. The order of the headers included by crystalhd.h considers the dependencies among the headers. Signed-off-by:
-
Andrew Miller authored
Fixed some coding style issues. Signed-off-by:
Andrew Miller <amiller@amilx.com> Signed-off-by:
-
Johannes Thumshirn authored
Signed-off-by:
Johannes Thumshirn <morbidrsa@googlemail.com> Signed-off-by:
-
Peter Huewe authored
This patch removes a superfluous loop in asus_oled.c The code is equivalent to do{...} while (0) and thus executes the code exactly once -> so we can simply remove the loop. Signed-off-by:Peter Huewe <peterhuewe@gmx.de> Signed-off-by:
-
Tomas Winkler authored
Replace bitfield struct hbm_cmd with simple u8 as we always access the value as whole. This allows us to remove few ugly type casts For possible further uses and documentation purposes we add corresponding bitmask defines Signed-off-by:
Tomas Winkler <tomas.winkler@intel.com> Signed-off-by:
-
Devin J. Pohly authored
~ENODEV is a different number than -ENODEV Signed-off-by:
Devin J. Pohly <djpohly@gmail.com> Signed-off-by:
-
Greg Kroah-Hartman authored
-
Seth Jennings authored
This patch fixes a bug where the zv code writes before the allocated buffer, resulting in system memory corruption. This was introduced during the switch from xvmalloc to zsmalloc. Signed-off-by:
Seth Jennings <sjenning@linux.vnet.ibm.com> Signed-off-by:
-
Seth Jennings authored
This fixes a type mismatch in the compression code where a size_t pointer was cast to a unsigned int pointer. On little endian archs, there is no issue. However on big endian archs, the value is incorrect, taking the high order bits and truncating the lower order bits. Signed-off-by:
-
Chris Kelly authored
This structure is used in an ioctl definition and was causing the 64-bit PowerPC build to fail. The size of the array in the structure has been reduced to fix this. Signed-off-by:
Chris Kelly <ckelly@ozmodevices.com> Reported-by:
Stephen Rothwell <sfr@canb.auug.org.au> Signed-off-by:
-
- 24 Feb, 2012 24 commits
-
-
Michael Hennerich authored
The core must not modify available_scan_mask, because it causes problems with drivers where multiple instances of the driver share the same mask set. So make this explicit by marking available scan masks as const. The max1363 driver needs some minor adjustment to accommodate this change. Pull scan mask allocation into a separate function. Signed-off-by:
Michael Hennerich <michael.hennerich@analog.com> Acked-by:
Jonathan Cameron <jic23@kernel.org> Signed-off-by:
-
Lars-Peter Clausen authored
The declaration for iio_buffer_deinit has been around for quite some time, but the function itself has never been added. So remove the declaration. Signed-off-by:
Lars-Peter Clausen <lars@metafoo.de> Acked-by:
-
Lars-Peter Clausen authored
The AD5666 is identical to the ad5064-1, except that it has a internal reference voltage. Signed-off-by:
-
Lars-Peter Clausen authored
The AD5628/AD5648/AD5668 are similar to the AD5024/AD5044/AD5064. The difference being that they have an internal reference voltage and 8 instead of 4 DAC channels. Signed-off-by:
-
Lars-Peter Clausen authored
The AD5025/AD5045/AD5065 are identical to the AD5024/AD5044/AD5064 except that they have 2 instead of 4 DAC channels. Signed-off-by:
-
Lars-Peter Clausen authored
Prepare the driver for the addition of chip variants with a different number of channels. This is done by not hard-coding the number of channels, but instead add a field to the chip info struct holding the number of channels. Also do not embed the channel specs into the chip info, but rather store them independently. This allows sharing the same channel spec between different chip infos. Signed-off-by:
-
Lars-Peter Clausen authored
Use extended channel info attributes for the powerdown, powerdown_mode and powerdown_mode_available attributes. Note that this patch moves the chip info defintion around to avoid having to use forward declarations for the extended channel info attributes callbacks. Signed-off-by:
-
Lars-Peter Clausen authored
Sometimes devices have per channel properties which either do not map nicely to the current channel info scheme (e.g. string properties) or are very device specific, so it does not make sense to add generic support for them. Currently drivers define these attributes by hand for each channel. Depending on the number of channels this can amount to quite a few lines of boilerplate code. Especially if a driver supports multiple variations of a chip with different numbers of channels. In this case it becomes necessary to have a individual attribute list per chip variation and also a individual iio_info struct. This patch introduces a new scheme for handling such per channel attributes called extended channel info attributes. A extended channel info attribute consist of a name, a flag whether it is shared and read and write callbacks. The read and write callbacks are similar to the {read,write}_raw callbacks and take a IIO device and a channel as their first parameters, but instead of pre-parsed integer values they directly get passed the raw string value, which has been written to the sysfs file. It is possible to assign a list of extended channel info attributes to a channel. For each extended channel info attribute the IIO core will create a new sysfs attribute conforming to the IIO channel naming spec for the channels type, similar as for normal info attributes. Read and write access to this sysfs attribute will be redirected to the extended channel info attributes read and write callbacks. Signed-off-by: -
Lars-Peter Clausen authored
Convert the IIO drivers which have not been converted yet to module_spi_driver. Signed-off-by:
-
Lars-Peter Clausen authored
Use dev_pm_ops instead of legacy suspend/resume callbacks for IIO drivers. Note that this patch introduces a few new #ifdef CONFIG_PM_SLEEP around the suspend and resume callbacks to avoid warnings of unused functions if CONFIG_PM_SLEEP is not defined. Signed-off-by:
-
Jonathan Cameron authored
Very basic description of the way iio consumers work and how to use this functionality. Signed-off-by:
Linus Walleij <linus.walleij@linaro.org> Signed-off-by:
-
Jonathan Cameron authored
Direct copy of version proposed for the non staging branch. Needed here to allow testing of more advanced inkernel interface code. Minimal support of simple in, curr and temp attributes so far. Signed-off-by:
-
Jonathan Cameron authored
In kernel interfaces need these, so make them available. Signed-off-by:
-
Jonathan Cameron authored
Lifted from proposal for in kernel interface built on the out of staging branch. Two elements here: * Map as defined in "inkern.h" * Matching code to actually get the iio_dev and channel that we want from the global list of IIO devices. V4: Everything now built if iio is built (rather than being optional) Removal race condition prevented by using info pointer as a check of removal under a lock. V3: Drop the option of registering / getting channels using dev pointer. Stick to name only as suggested by Mark Brown (this has caused user confusion in the regulator framework.) V2: As per Greg KH suggestion, move over to registration by passing the tables into the provider drivers (how regulator does it). This does not prevent us using the original more flexible approach if at a later date there is a usecase that demands it. Signed-off-by: -
Jonathan Cameron authored
This prevents use of provider callbacks after it has been unregistered. Note that all code using this that can be called from a consumer *must* check the pointer before using and hold the info_exist_lock throughout the usage of the callbacks in info. Signed-off-by:
-
Omar Ramirez Luna authored
In order to detect WDT feature on the dsp code, we need to find the symbol used to enable it inside the baseimage. This should fix the warning comming from L3 driver: WARNING: at arch/arm/mach-omap2/omap_l3_smx.c:161 omap3_l3_app_irq... In-band Error seen by IVA_SS at address 0 ... That occurs because the dsp tries to access wdt3 registers when the clock for those registers is not enabled. Reported-by:Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by:
Omar Ramirez Luna <omar.ramirez@ti.com> Signed-off-by:
-
Omar Ramirez Luna authored
In order to detect it at runtime, we need the code handling wdt clock available at runtime to decide whether to enable or disable based on the baseimage symbols. Default timeout has been set to 5 seconds. Downside is that we will lose the option to set a custom timeout for overflow, but than can be added (if needed) as part of debugfs. Signed-off-by:
-
Masanari Iida authored
Correct spelling "erorr" to "error" in drivers/stating/comedi/drivers/unioxx5.c Signed-off-by:
Masanari Iida <standby24x7@gmail.com> Signed-off-by:
-
Masanari Iida authored
Correct spelling "scaning" to "scanning" in drivers/staging/vt6656/bssdb.c drivers/staging/vt6655/bssdb.c Signed-off-by:
-
David Daney authored
Commit d6c25be (mdio-octeon: use an unique MDIO bus name.) changed the names used to refer to MDIO buses. The ethernet driver must be changed to match, so that the PHY drivers can be attached. Signed-off-by:
David Daney <david.daney@cavium.com> Acked-by:
Florian Fainelli <florian@openwrt.org> Cc: stable <stable@vger.kernel.org> Signed-off-by:
-
Rabin Vincent authored
The readers list is traversed under the log->mutex lock (for example from fix_up_readers()), but the deletion of elements from this list is not being done under this lock. Cc: Brian Swetland <swetland@google.com> Cc: Dima Zavin <dima@android.com> Signed-off-by:
Rabin Vincent <rabin.vincent@stericsson.com> Signed-off-by:
-
Chris Ball authored
These are each >20k LOC drivers that embed an entire SD stack, and present SD cards as if they were SCSI devices; both drivers should be rewritten to be small hooks that connect the PCI (for rts_pstor) or USB (for rts5139) hardware into Linux's MMC/xD/memorystick stacks. Signed-off-by:
Chris Ball <cjb@laptop.org> Cc: edwin_rong <edwin_rong@realsil.com.cn> Signed-off-by:
-
Dan Carpenter authored
p80211item_pstr6_t is the size of "msg1.bssid" (16 bytes) but msg1.bssid.data is type p80211pstr6_t and it is smaller (7 bytes). We had just set that memory to zeroes earlier and now we're writing over it with 0xff because we're writing past the end of the struct. I don't know if this actually causes a problem. It may be that we initialize the extra 0xff bytes correctly later. But the current code is obviously wrong and we should fix it. Signed-off-by:
-
Danny Kukawka authored
Unify return value of .ndo_set_mac_address if the given address isn't valid. Return -EADDRNOTAVAIL as eth_mac_addr() already does if is_valid_ether_addr() fails. Signed-off-by:
Danny Kukawka <danny.kukawka@bisect.de> Signed-off-by:
-
