| Age | Commit message (Collapse) | Author |
|---|
|
SG mode is not currently supported by netvsc, so remove this flag for now.
Otherwise, it will be unconditionally enabled by commit ec5f0615642
"Kill link between CSUM and SG features"
Previously, the SG feature is disabled because CSUM is not set here.
Signed-off-by: Haiyang Zhang <haiyangz@microsoft.com>
Reviewed-by: K. Y. Srinivasan <kys@microsoft.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Fix new kernel-doc warning in drivers/base/platform.c:
Warning(drivers/base/platform.c:528): No description found for parameter 'owner'
Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/jic23/iio into staging-linus
Jonathan writes:
The first round of IIO fixes for the 3.11 cycle.
This set is larger than I would like, partly due to my lack of review
time in the weeks before the merge window and partly because a
couple of large drivers and the subsystem as a whole seem to be
getting a lot more exposure and testing recently.
1) A long term bug in trigger handling gave a double free of the device.
2) Wrong return value handling means offsets are ignored in
iio_convert_raw_to_processed_unlocked.
3) The iio_channel_has_info utility function was incorrectly updated
during the recent info_mask split, this is now fixed.
4) mxs-lradc has a couple of little fixes.
5) A couple of missing .driver_module entries meant that drivers
could be removed from underneath their users.
6) Error path fixes for ad7303 and lis3l02dq.
7) The scale value for presure in the lps331ap driver was out by
a factor of 100.
|
|
This driver is not being updated as the specifications are not able to
be gotten from CSR or anyone else. Without those, getting this driver
into proper mergable shape is going to be impossible. So remove the
driver from the tree.
If the specifications ever become available, this patch can be reverted
and the driver fixed up properly.
Reported-by: Lidza Louina <lidza.louina@gmail.com>
Cc: Veli-Pekka Peltola <veli-pekka.peltola@bluegiga.com>
Cc: Mikko Virkkilä <mikko.virkkila@bluegiga.com>
Cc: Lauri Hintsala <Lauri.Hintsala@bluegiga.com>
Cc: Riku Mettälä <riku.mettala@bluegiga.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
into for-3.11/drivers
Kent writes:
Hey Jens - I've been busy torture testing and chasing bugs, here's the
fruits of my labors. These are all fairly small fixes, some of them
quite important.
|
|
git://people.freedesktop.org/~danvet/drm-intel
One feature latecomer, I've forgotten to merge the patch to reeanble the
Haswell power well feature now that the audio interaction is fixed up.
Since that was the only unfixed issue with it I've figured I could throw
it in a bit late, and it's trivial to revert in case I'm wrong.
Otherwise all bug/regression fixes:
- Fix status page reinit after gpu hangs, spotted by more paranoid igt
checks.
- Fix object list walking fumble regression in the shrinker (only the
counting part, the actual shrinking code was correct so no Oops
potential), from Xiong Zhang.
- Fix DP 1.2 bw limits (Imre).
- Restore legacy forcewake on ivb, too many broken biosen out there. We
dump a warn though that recent userspace might fall over with that
config (Guenter Roeck).
- Patch up the gen2 cs tlb w/a.
- Improve the fence coherency w/a now that we have a better understanding
what's going on. The removed wbinvd+ipi should make -rt folks happy. Big
thanks to Jon Bloomfield for figuring this out, patches from Chris.
- Fix write-read race when switching ring (Chris). Spotted with code
inspection, but now we also have an igt for it.
There's an ugly regression we're still working on introduced between
3.10-rc7 and 3.10.0. Unfortunately we can't just revert the offender since
that one fixes another regression :( I've asked Steven to include my
-fixes branch into linux-next to prevent such fallout in the future,
hopefully.
* tag 'drm-intel-fixes-2013-07-11' of git://people.freedesktop.org/~danvet/drm-intel:
Revert "drm/i915: Workaround incoherence between fences and LLC across multiple CPUs"
drm/i915: Fix incoherence with fence updates on Sandybridge+
drm/i915: Fix write-read race with multiple rings
Partially revert "drm/i915: unconditionally use mt forcewake on hsw/ivb"
drm/i915: fix lane bandwidth capping for DP 1.2 sinks
drm/i915: fix up ring cleanup for the i830/i845 CS tlb w/a
drm/i915: Correct obj->mm_list link to dev_priv->dev_priv->mm.inactive_list
drm/i915: switch disable_power_well default value to 1
drm/i915: reinit status page registers after gpu reset
|
|
The hub driver was recently changed to use "global" suspend for system
suspend transitions on non-SuperSpeed buses. This means that we don't
suspend devices individually by setting the suspend feature on the
upstream hub port; instead devices all go into suspend automatically
when the root hub stops transmitting packets. The idea was to save
time and to avoid certain kinds of wakeup races.
Now it turns out that many hubs are buggy; they don't relay wakeup
requests from a downstream port to their upstream port if the
downstream port's suspend feature is not set (depending on the speed
of the downstream port, whether or not the hub is enabled for remote
wakeup, and possibly other factors).
We can't have hubs dropping wakeup requests. Therefore this patch
goes partway back to the old policy: It sets the suspend feature for a
port if the device attached to that port or any of its descendants is
enabled for wakeup. People will still be able to benefit from the
time savings if they don't care about wakeup and leave it disabled on
all their devices.
In order to accomplish this, the patch adds a new field to the usb_hub
structure: wakeup_enabled_descendants is a count of how many devices
below a suspended hub are enabled for remote wakeup. A corresponding
new subroutine determines the number of wakeup-enabled devices at or
below an arbitrary suspended USB device.
This should be applied to the 3.10 stable kernel.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
Reported-and-tested-by: Toralf Förster <toralf.foerster@gmx.de>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
commit 2f7021a8 "cpufreq: protect 'policy->cpus' from offlining
during __gov_queue_work()" caused a regression in CPU hotplug,
because it lead to a deadlock between cpufreq governor worker thread
and the CPU hotplug writer task.
Lockdep splat corresponding to this deadlock is shown below:
[ 60.277396] ======================================================
[ 60.277400] [ INFO: possible circular locking dependency detected ]
[ 60.277407] 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744 Not tainted
[ 60.277411] -------------------------------------------------------
[ 60.277417] bash/2225 is trying to acquire lock:
[ 60.277422] ((&(&j_cdbs->work)->work)){+.+...}, at: [<ffffffff810621b5>] flush_work+0x5/0x280
[ 60.277444] but task is already holding lock:
[ 60.277449] (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81042d8b>] cpu_hotplug_begin+0x2b/0x60
[ 60.277465] which lock already depends on the new lock.
[ 60.277472] the existing dependency chain (in reverse order) is:
[ 60.277477] -> #2 (cpu_hotplug.lock){+.+.+.}:
[ 60.277490] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.277503] [<ffffffff815b6157>] mutex_lock_nested+0x67/0x410
[ 60.277514] [<ffffffff81042cbc>] get_online_cpus+0x3c/0x60
[ 60.277522] [<ffffffff814b842a>] gov_queue_work+0x2a/0xb0
[ 60.277532] [<ffffffff814b7891>] cs_dbs_timer+0xc1/0xe0
[ 60.277543] [<ffffffff8106302d>] process_one_work+0x1cd/0x6a0
[ 60.277552] [<ffffffff81063d31>] worker_thread+0x121/0x3a0
[ 60.277560] [<ffffffff8106ae2b>] kthread+0xdb/0xe0
[ 60.277569] [<ffffffff815bb96c>] ret_from_fork+0x7c/0xb0
[ 60.277580] -> #1 (&j_cdbs->timer_mutex){+.+...}:
[ 60.277592] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.277600] [<ffffffff815b6157>] mutex_lock_nested+0x67/0x410
[ 60.277608] [<ffffffff814b785d>] cs_dbs_timer+0x8d/0xe0
[ 60.277616] [<ffffffff8106302d>] process_one_work+0x1cd/0x6a0
[ 60.277624] [<ffffffff81063d31>] worker_thread+0x121/0x3a0
[ 60.277633] [<ffffffff8106ae2b>] kthread+0xdb/0xe0
[ 60.277640] [<ffffffff815bb96c>] ret_from_fork+0x7c/0xb0
[ 60.277649] -> #0 ((&(&j_cdbs->work)->work)){+.+...}:
[ 60.277661] [<ffffffff810ab826>] __lock_acquire+0x1766/0x1d30
[ 60.277669] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.277677] [<ffffffff810621ed>] flush_work+0x3d/0x280
[ 60.277685] [<ffffffff81062d8a>] __cancel_work_timer+0x8a/0x120
[ 60.277693] [<ffffffff81062e53>] cancel_delayed_work_sync+0x13/0x20
[ 60.277701] [<ffffffff814b89d9>] cpufreq_governor_dbs+0x529/0x6f0
[ 60.277709] [<ffffffff814b76a7>] cs_cpufreq_governor_dbs+0x17/0x20
[ 60.277719] [<ffffffff814b5df8>] __cpufreq_governor+0x48/0x100
[ 60.277728] [<ffffffff814b6b80>] __cpufreq_remove_dev.isra.14+0x80/0x3c0
[ 60.277737] [<ffffffff815adc0d>] cpufreq_cpu_callback+0x38/0x4c
[ 60.277747] [<ffffffff81071a4d>] notifier_call_chain+0x5d/0x110
[ 60.277759] [<ffffffff81071b0e>] __raw_notifier_call_chain+0xe/0x10
[ 60.277768] [<ffffffff815a0a68>] _cpu_down+0x88/0x330
[ 60.277779] [<ffffffff815a0d46>] cpu_down+0x36/0x50
[ 60.277788] [<ffffffff815a2748>] store_online+0x98/0xd0
[ 60.277796] [<ffffffff81452a28>] dev_attr_store+0x18/0x30
[ 60.277806] [<ffffffff811d9edb>] sysfs_write_file+0xdb/0x150
[ 60.277818] [<ffffffff8116806d>] vfs_write+0xbd/0x1f0
[ 60.277826] [<ffffffff811686fc>] SyS_write+0x4c/0xa0
[ 60.277834] [<ffffffff815bbbbe>] tracesys+0xd0/0xd5
[ 60.277842] other info that might help us debug this:
[ 60.277848] Chain exists of:
(&(&j_cdbs->work)->work) --> &j_cdbs->timer_mutex --> cpu_hotplug.lock
[ 60.277864] Possible unsafe locking scenario:
[ 60.277869] CPU0 CPU1
[ 60.277873] ---- ----
[ 60.277877] lock(cpu_hotplug.lock);
[ 60.277885] lock(&j_cdbs->timer_mutex);
[ 60.277892] lock(cpu_hotplug.lock);
[ 60.277900] lock((&(&j_cdbs->work)->work));
[ 60.277907] *** DEADLOCK ***
[ 60.277915] 6 locks held by bash/2225:
[ 60.277919] #0: (sb_writers#6){.+.+.+}, at: [<ffffffff81168173>] vfs_write+0x1c3/0x1f0
[ 60.277937] #1: (&buffer->mutex){+.+.+.}, at: [<ffffffff811d9e3c>] sysfs_write_file+0x3c/0x150
[ 60.277954] #2: (s_active#61){.+.+.+}, at: [<ffffffff811d9ec3>] sysfs_write_file+0xc3/0x150
[ 60.277972] #3: (x86_cpu_hotplug_driver_mutex){+.+...}, at: [<ffffffff81024cf7>] cpu_hotplug_driver_lock+0x17/0x20
[ 60.277990] #4: (cpu_add_remove_lock){+.+.+.}, at: [<ffffffff815a0d32>] cpu_down+0x22/0x50
[ 60.278007] #5: (cpu_hotplug.lock){+.+.+.}, at: [<ffffffff81042d8b>] cpu_hotplug_begin+0x2b/0x60
[ 60.278023] stack backtrace:
[ 60.278031] CPU: 3 PID: 2225 Comm: bash Not tainted 3.10.0-rc7-dbg-01385-g241fd04-dirty #1744
[ 60.278037] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011
[ 60.278042] ffffffff8204e110 ffff88014df6b9f8 ffffffff815b3d90 ffff88014df6ba38
[ 60.278055] ffffffff815b0a8d ffff880150ed3f60 ffff880150ed4770 3871c4002c8980b2
[ 60.278068] ffff880150ed4748 ffff880150ed4770 ffff880150ed3f60 ffff88014df6bb00
[ 60.278081] Call Trace:
[ 60.278091] [<ffffffff815b3d90>] dump_stack+0x19/0x1b
[ 60.278101] [<ffffffff815b0a8d>] print_circular_bug+0x2b6/0x2c5
[ 60.278111] [<ffffffff810ab826>] __lock_acquire+0x1766/0x1d30
[ 60.278123] [<ffffffff81067e08>] ? __kernel_text_address+0x58/0x80
[ 60.278134] [<ffffffff810ac6d4>] lock_acquire+0xa4/0x200
[ 60.278142] [<ffffffff810621b5>] ? flush_work+0x5/0x280
[ 60.278151] [<ffffffff810621ed>] flush_work+0x3d/0x280
[ 60.278159] [<ffffffff810621b5>] ? flush_work+0x5/0x280
[ 60.278169] [<ffffffff810a9b14>] ? mark_held_locks+0x94/0x140
[ 60.278178] [<ffffffff81062d77>] ? __cancel_work_timer+0x77/0x120
[ 60.278188] [<ffffffff810a9cbd>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 60.278196] [<ffffffff81062d8a>] __cancel_work_timer+0x8a/0x120
[ 60.278206] [<ffffffff81062e53>] cancel_delayed_work_sync+0x13/0x20
[ 60.278214] [<ffffffff814b89d9>] cpufreq_governor_dbs+0x529/0x6f0
[ 60.278225] [<ffffffff814b76a7>] cs_cpufreq_governor_dbs+0x17/0x20
[ 60.278234] [<ffffffff814b5df8>] __cpufreq_governor+0x48/0x100
[ 60.278244] [<ffffffff814b6b80>] __cpufreq_remove_dev.isra.14+0x80/0x3c0
[ 60.278255] [<ffffffff815adc0d>] cpufreq_cpu_callback+0x38/0x4c
[ 60.278265] [<ffffffff81071a4d>] notifier_call_chain+0x5d/0x110
[ 60.278275] [<ffffffff81071b0e>] __raw_notifier_call_chain+0xe/0x10
[ 60.278284] [<ffffffff815a0a68>] _cpu_down+0x88/0x330
[ 60.278292] [<ffffffff81024cf7>] ? cpu_hotplug_driver_lock+0x17/0x20
[ 60.278302] [<ffffffff815a0d46>] cpu_down+0x36/0x50
[ 60.278311] [<ffffffff815a2748>] store_online+0x98/0xd0
[ 60.278320] [<ffffffff81452a28>] dev_attr_store+0x18/0x30
[ 60.278329] [<ffffffff811d9edb>] sysfs_write_file+0xdb/0x150
[ 60.278337] [<ffffffff8116806d>] vfs_write+0xbd/0x1f0
[ 60.278347] [<ffffffff81185950>] ? fget_light+0x320/0x4b0
[ 60.278355] [<ffffffff811686fc>] SyS_write+0x4c/0xa0
[ 60.278364] [<ffffffff815bbbbe>] tracesys+0xd0/0xd5
[ 60.280582] smpboot: CPU 1 is now offline
The intention of that commit was to avoid warnings during CPU
hotplug, which indicated that offline CPUs were getting IPIs from the
cpufreq governor's work items. But the real root-cause of that
problem was commit a66b2e5 (cpufreq: Preserve sysfs files across
suspend/resume) because it totally skipped all the cpufreq callbacks
during CPU hotplug in the suspend/resume path, and hence it never
actually shut down the cpufreq governor's worker threads during CPU
offline in the suspend/resume path.
Reflecting back, the reason why we never suspected that commit as the
root-cause earlier, was that the original issue was reported with
just the halt command and nobody had brought in suspend/resume to the
equation.
The reason for _that_ in turn, as it turns out, is that earlier
halt/shutdown was being done by disabling non-boot CPUs while tasks
were frozen, just like suspend/resume.... but commit cf7df378a
(reboot: migrate shutdown/reboot to boot cpu) which came somewhere
along that very same time changed that logic: shutdown/halt no longer
takes CPUs offline. Thus, the test-cases for reproducing the bug
were vastly different and thus we went totally off the trail.
Overall, it was one hell of a confusion with so many commits
affecting each other and also affecting the symptoms of the problems
in subtle ways. Finally, now since the original problematic commit
(a66b2e5) has been completely reverted, revert this intermediate fix
too (2f7021a8), to fix the CPU hotplug deadlock. Phew!
Reported-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Reported-by: Bartlomiej Zolnierkiewicz <b.zolnierkie@samsung.com>
Signed-off-by: Srivatsa S. Bhat <srivatsa.bhat@linux.vnet.ibm.com>
Tested-by: Peter Wu <lekensteyn@gmail.com>
Cc: 3.10+ <stable@vger.kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
|
|
Hardware workaround requesting hardware to skip vlan insertion is necessary
only when umc or qnq is enabled. Enabling this workaround in other scenarios
could cause controller to stall.
Signed-off-by: Sarveshwar Bandi <sarveshwar.bandi@emulex.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
The hard-coded 8021.q proto will break 802.1ad traffic. So switch to use
vlan->proto.
Cc: Basil Gor <basil.gor@gmail.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Commit 441ac0fcaadc76ad09771812382345001dd2b813
(macvtap: Convert to using rtnl lock) forget to return what
macvtap_ioctl_set_queue() returns to its caller. This may break multiqueue API
by always falling through to TUNGETFEATURES.
Cc: Vlad Yasevich <vyasevic@redhat.com>
Signed-off-by: Jason Wang <jasowang@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Cc: Eli Cohen <eli@mellanox.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Acked-by: Randy Dunlap <rdunlap@infradead.org>
Reported-by: Randy Dunlap <rdunlap@infradead.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
bgmac is using functions from phylib, add the dependency.
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
Ben Hutchings pointed out that my recent update to atl1e
in commit 352900b583b2852152a1e05ea0e8b579292e731e
("atl1e: fix dma mapping warnings") was missing a bit of code.
Specifically it reset the hardware tx ring to its origional state when
we hit a dma error, but didn't unmap any exiting mappings from the
operation. This patch fixes that up. It also remembers to free the
skb in the event that an error occurs, so we don't leak. Untested, as
I don't have hardware. I think its pretty straightforward, but please
review closely.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
CC: Ben Hutchings <bhutchings@solarflare.com>
CC: Jay Cliburn <jcliburn@gmail.com>
CC: Chris Snook <chris.snook@gmail.com>
CC: "David S. Miller" <davem@davemloft.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
|
|
We should be using groups, not attribute lists, for classes to allow
subdirectories, and soon, binary files. Groups are just more flexible
overall, so add them.
The dev_attrs list will go away after all in-kernel users are converted
to use dev_groups.
Reviewed-by: Guenter Roeck <linux@roeck-us.net>
Tested-by: Guenter Roeck <linux@roeck-us.net>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
device_create_groups lets callers create devices as well as associated
sysfs attributes with a single call. This avoids race conditions seen
if sysfs attributes on new devices are created later.
[fixed up comment block placement and add checks for printk buffer
formats - gregkh]
Signed-off-by: Guenter Roeck <linux@roeck-us.net>
Cc: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
|
|
There is a patch b55f84e2d527182e7c611d466cd0bb6ddce201de "ata_piix: Fix DVD
not dectected at some Haswell platforms" to fix an issue of DVD not
recognized on Haswell Desktop platform with Lynx Point.
Recently, it is also found the same issue at some platformas with Wellsburg PCH.
So deliver a similar patch to fix it by disables 32bit PIO in IDE mode.
Signed-off-by: Youquan Song <youquan.song@intel.com>
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: stable@vger.kernel.org
|
|
Bits 1-21 in this channel type attributes are indication for which
SSID is going to be sent on this channel. Since the first SSID is
sent implicitly in the probe request, we don't need to toggle its
bit here.
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Increment index in each iteration. Without this increment we are
overriding the added SSIDs and we will send only the last SSId
and (n_ssids - 1) broadcast probes.
Cc: <stable@vger.kernel.org> [3.9+]
Signed-off-by: David Spinadel <david.spinadel@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
Due to a firmware bug, it crashes when the beacon interval
is smaller than 16. Avoid this by refusing the station state
change creating the AP station, causing mac80211 to abandon
the attempt to connect to the AP, and eventually wpa_s to
blacklist it.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
|
|
The firmware / HW can't support more than 16 Rx BA sessions.
Deny any attemps to open more sessions than that.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
We didn't release the Rx AMPDU ressources properly.
This bug led to firmware assert after 16 BA sessions.
Cc: <stable@vger.kernel.org> [3.9+]
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
Avoid creating VIF specific debugfs directory if already exist.
This may happen when, for example, resetting hw, suspend-resume.
Signed-off-by: Alexander Bondar <alexander.bondar@intel.com>
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
The BT_CONFIG command that is sent to the device during
startup will enable BT coex unless the module parameter
turns it off, but on devices without Bluetooth this may
cause problems, as reported in Redhat BZ 885407.
Fix this by sending the BT_CONFIG command only when the
device has Bluetooth.
Cc: stable@vger.kernel.org
Reviewed-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
Fix a "set but not used" warning found via make W=1.
Signed-off-by: Sebastian Ott <sebott@linux.vnet.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
|
|
This was missing and prevented any further attempts
to load the module.
Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach@intel.com>
Signed-off-by: Johannes Berg <johannes@sipsolutions.net>
|
|
This patch fixes improper in_pressure_scale output that is
returned by the lps331ap barometer sensor driver. According
to the documentation the pressure after applying the scale has to
be expressed in kilopascal units. With erroneous implementation
the scale value larger by two orders of magnitude is returned -
2441410 instead of 24414.
Signed-off-by: Jacek Anaszewski <j.anaszewski@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Acked-by: Denis Ciocca <denis.ciocca@st.com>
Signed-off-by: Jonathan Cameron <jic23@kernel.org>
|
|
Although it is unlikley that physical package id is set to some
arbitary number, it is better to prevent in anycase. Since package
temp zones use this in thermal zone type and for allocation, added
a limit.
Signed-off-by: Srinivas Pandruvada <srinivas.pandruvada@linux.intel.com>
Signed-off-by: Zhang Rui <rui.zhang@intel.com>
|
|
Fixup for commit "uvesafb: Clean up MTRR code"
(63e28a7a5ffce59b645ca9cbcc01e1e8be56bd75)
Signed-off-by: Sylvain "ythier" Hitier <sylvain.hitier@gmail.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
Also-spotted-by: Torsten Kaiser <just.for.lkml@googlemail.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
|
|
More DPM fixes, r6xx DMA fix for bo moving, UVD fixes,
one major regression fix on bootup on some machine (ttm backoff missing)
* 'drm-fixes-3.11' of git://people.freedesktop.org/~agd5f/linux:
radeon kms: do not flush uninitialized hotplug work
drm/radeon/dpm/sumo: handle boost states properly when forcing a perf level
drm/radeon: align VM PTBs (Page Table Blocks) to 32K
drm/radeon: allow selection of alignment in the sub-allocator
drm/radeon: never unpin UVD bo v3
drm/radeon: fix UVD fence emit
drm/radeon: add fault decode function for CIK
drm/radeon: add fault decode function for SI (v2)
drm/radeon: add fault decode function for cayman/TN (v2)
drm/radeon: use radeon device for request firmware
drm/radeon: add missing ttm_eu_backoff_reservation to radeon_bo_list_validate
drm/radeon: use CP DMA on r6xx for bo moves
drm/radeon: implement bo copy callback using CP DMA (v2)
drm/radeon: Disable dma rings for bo moves on r6xx
drm/radeon/dpm: disable gfx PG on PALM
drm/radeon/hdmi: make sure we have an afmt block assigned
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap
Pull regmap fix from Mark Brown:
"Fix regmap crash for async operation on busless maps
This fixes a crash if something tries to do an asynchronous operation
on busless maps which was introduced during the merge window"
* tag 'regmap-v3.11-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/broonie/regmap:
regmap: cache: bail in regmap_async_complete() for bus-less maps
|
|
snd_pcm_stop() must be called in the PCM substream lock context.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
snd_pcm_stop() must be called in the PCM substream lock context.
Cc: <stable@vger.kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
|
|
Fix a warning from lockdep caused by calling flush_work() for
uninitialized hotplug work. Initialize hotplug_work, audio_work
and reset_work upon successful radeon_irq_kms_init() completion
and thus perform hotplug flush_work only when rdev->irq.installed
is true.
[ 4.790019] [drm] Loading CEDAR Microcode
[ 4.790943] r600_cp: Failed to load firmware "radeon/CEDAR_smc.bin"
[ 4.791152] [drm:evergreen_startup] *ERROR* Failed to load firmware!
[ 4.791330] radeon 0000:01:00.0: disabling GPU acceleration
[ 4.792633] INFO: trying to register non-static key.
[ 4.792792] the code is fine but needs lockdep annotation.
[ 4.792953] turning off the locking correctness validator.
[ 4.793114] CPU: 2 PID: 1 Comm: swapper/0 Not tainted 3.11.0-rc0-dbg-10676-gfe56456-dirty #1816
[ 4.793314] Hardware name: Acer Aspire 5741G /Aspire 5741G , BIOS V1.20 02/08/2011
[ 4.793507] ffffffff821fd810 ffff8801530b9a18 ffffffff8160434e 0000000000000002
[ 4.794155] ffff8801530b9ad8 ffffffff810b8404 ffff8801530b0798 ffff8801530b0000
[ 4.794789] ffff8801530b9b00 0000000000000046 00000000000004c0 ffffffff00000000
[ 4.795418] Call Trace:
[ 4.795573] [<ffffffff8160434e>] dump_stack+0x4e/0x82
[ 4.795731] [<ffffffff810b8404>] __lock_acquire+0x1a64/0x1d30
[ 4.795893] [<ffffffff814a87f0>] ? dev_vprintk_emit+0x50/0x60
[ 4.796034] [<ffffffff810b8fb4>] lock_acquire+0xa4/0x200
[ 4.796216] [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[ 4.796375] [<ffffffff8106cdad>] flush_work+0x3d/0x280
[ 4.796520] [<ffffffff8106cd75>] ? flush_work+0x5/0x280
[ 4.796682] [<ffffffff810b659d>] ? trace_hardirqs_on_caller+0xfd/0x1c0
[ 4.796862] [<ffffffff8131d775>] ? delay_tsc+0x95/0xf0
[ 4.797024] [<ffffffff8141bb8b>] radeon_irq_kms_fini+0x2b/0x70
[ 4.797186] [<ffffffff814557c9>] evergreen_init+0x2a9/0x2e0
[ 4.797347] [<ffffffff813ebb1f>] radeon_device_init+0x5ef/0x700
[ 4.797511] [<ffffffff81335bc7>] ? pci_find_capability+0x47/0x50
[ 4.797672] [<ffffffff813edaed>] radeon_driver_load_kms+0x8d/0x150
[ 4.797843] [<ffffffff813ce426>] drm_get_pci_dev+0x166/0x280
[ 4.798007] [<ffffffff8116cff5>] ? kfree+0xf5/0x2e0
[ 4.798168] [<ffffffff813ea298>] ? radeon_pci_probe+0x98/0xd0
[ 4.798329] [<ffffffff813ea2aa>] radeon_pci_probe+0xaa/0xd0
[ 4.798489] [<ffffffff81339404>] pci_device_probe+0x84/0xe0
[ 4.798644] [<ffffffff814ac7d6>] driver_probe_device+0x76/0x240
[ 4.798805] [<ffffffff814aca73>] __driver_attach+0x93/0xa0
[ 4.798948] [<ffffffff814ac9e0>] ? __device_attach+0x40/0x40
[ 4.799126] [<ffffffff814aa82b>] bus_for_each_dev+0x6b/0xb0
[ 4.799272] [<ffffffff814ac2be>] driver_attach+0x1e/0x20
[ 4.799434] [<ffffffff814abec0>] bus_add_driver+0x1f0/0x280
[ 4.799596] [<ffffffff814ad0e4>] driver_register+0x74/0x150
[ 4.799758] [<ffffffff8133923d>] __pci_register_driver+0x5d/0x60
[ 4.799936] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[ 4.800081] [<ffffffff813ce655>] drm_pci_init+0x115/0x130
[ 4.800243] [<ffffffff81d16efc>] ? ttm_init+0x67/0x67
[ 4.800405] [<ffffffff81d16f98>] radeon_init+0x9c/0xba
[ 4.800586] [<ffffffff810002ca>] do_one_initcall+0xfa/0x150
[ 4.800746] [<ffffffff81073f60>] ? parse_args+0x120/0x330
[ 4.800909] [<ffffffff81cdafae>] kernel_init_freeable+0x111/0x191
[ 4.801052] [<ffffffff81cda87a>] ? do_early_param+0x88/0x88
[ 4.801233] [<ffffffff815fb670>] ? rest_init+0x140/0x140
[ 4.801393] [<ffffffff815fb67e>] kernel_init+0xe/0x180
[ 4.801556] [<ffffffff8160dcac>] ret_from_fork+0x7c/0xb0
[ 4.801718] [<ffffffff815fb670>] ? rest_init+0x140/0x140
Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
Need to properly enable/disable boost states when forcing a performance
level.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
|
|
Covers requirements of all current asics.
Reviewed-by: Christian König <christian.koenig@amd.com>
Signed-off-by: Alex Deucher <alexander.deucher@amd.com>
Cc: stable@vger.kernel.org
|
|
|
|
|
|
|
|
Correction of the omap_usb3_dpll_params array when the sys_clk_rate is
20MHz.
Signed-off-by: Nikhil Devshatwar <nikhil.nd@ti.com>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
The error message is common to both clk_get functions. Update it
accordingly.
Signed-off-by: Sachin Kamat <sachin.kamat@linaro.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
When CONFIG_HAS_DMA isn't enabled, the UDC core gets build errors:
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
drivers/built-in.o: In function `usb_gadget_unmap_request':
drivers/usb/gadget/udc-core.c:91: undefined reference to `dma_unmap_sg'
drivers/usb/gadget/udc-core.c:96: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `usb_gadget_map_request':
drivers/usb/gadget/udc-core.c:62: undefined reference to `dma_map_sg'
drivers/usb/gadget/udc-core.c:71: undefined reference to `dma_map_single'
drivers/usb/gadget/udc-core.c:74: undefined reference to `dma_mapping_error'
Prevent this by protecting the DMA API routines with preprocessor tests.
Signed-off-by: Alan Stern <stern@rowland.harvard.edu>
CC: Geert Uytterhoeven <geert@linux-m68k.org>
Acked-by: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If NO_DMA=y:
drivers/built-in.o: In function `mv_u3d_done':
drivers/usb/gadget/mv_u3d_core.c:206: undefined reference to `dma_pool_free'
drivers/usb/gadget/mv_u3d_core.c:209: undefined reference to `dma_unmap_single'
drivers/built-in.o: In function `mv_u3d_build_trb_one':
drivers/usb/gadget/mv_u3d_core.c:311: undefined reference to `dma_pool_alloc'
drivers/built-in.o: In function `mv_u3d_req_to_trb':
drivers/usb/gadget/mv_u3d_core.c:480: undefined reference to `dma_map_single'
drivers/built-in.o: In function `mv_u3d_remove':
drivers/usb/gadget/mv_u3d_core.c:1770: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_u3d_core.c:1773: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `mv_u3d_probe':
drivers/usb/gadget/mv_u3d_core.c:1880: undefined reference to `dma_alloc_coherent'
drivers/usb/gadget/mv_u3d_core.c:1890: undefined reference to `dma_pool_create'
drivers/usb/gadget/mv_u3d_core.c:1984: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_u3d_core.c:1986: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If NO_DMA=y:
drivers/built-in.o: In function `fotg210_start_dma':
drivers/usb/gadget/fotg210-udc.c:354: undefined reference to `dma_map_single'
drivers/usb/gadget/fotg210-udc.c:357: undefined reference to `dma_mapping_error'
drivers/usb/gadget/fotg210-udc.c:362: undefined reference to `dma_sync_single_for_cpu'
drivers/usb/gadget/fotg210-udc.c:376: undefined reference to `dma_unmap_single'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If NO_DMA=y:
drivers/built-in.o: In function `done':
drivers/usb/gadget/mv_udc_core.c:239: undefined reference to `dma_pool_free'
drivers/built-in.o: In function `build_dtd':
drivers/usb/gadget/mv_udc_core.c:371: undefined reference to `dma_pool_alloc'
drivers/built-in.o: In function `udc_prime_status':
drivers/usb/gadget/mv_udc_core.c:1465: undefined reference to `dma_map_single'
drivers/built-in.o: In function `mv_udc_remove':
drivers/usb/gadget/mv_udc_core.c:2087: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_udc_core.c:2090: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `mv_udc_probe':
drivers/usb/gadget/mv_udc_core.c:2190: undefined reference to `dma_alloc_coherent'
drivers/usb/gadget/mv_udc_core.c:2201: undefined reference to `dma_pool_create'
drivers/usb/gadget/mv_udc_core.c:2315: undefined reference to `dma_pool_destroy'
drivers/usb/gadget/mv_udc_core.c:2317: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
If NO_DMA=y:
drivers/built-in.o: In function `dwc3_free_one_event_buffer':
drivers/usb/dwc3/core.c:132: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `dwc3_alloc_one_event_buffer':
drivers/usb/dwc3/core.c:154: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `dma_set_coherent_mask':
include/linux/dma-mapping.h:93: undefined reference to `dma_supported'
drivers/built-in.o: In function `dwc3_free_trb_pool':
drivers/usb/dwc3/gadget.c:407: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `dwc3_gadget_exit':
drivers/usb/dwc3/gadget.c:2693: undefined reference to `dma_free_coherent'
drivers/built-in.o: In function `dwc3_alloc_trb_pool':
drivers/usb/dwc3/gadget.c:391: undefined reference to `dma_alloc_coherent'
drivers/built-in.o: In function `dwc3_gadget_init':
drivers/usb/dwc3/gadget.c:2598: undefined reference to `dma_alloc_coherent'
drivers/usb/dwc3/gadget.c:2667: undefined reference to `dma_free_coherent'
drivers/usb/dwc3/gadget.c:2674: undefined reference to `dma_free_coherent'
drivers/usb/dwc3/gadget.c:2678: undefined reference to `dma_free_coherent'
Signed-off-by: Geert Uytterhoeven <geert@linux-m68k.org>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
USB_CONFIGFS_RNDIS depends on USB_U_RNDIS. Select it.
Acked-by: Michal Nazarewicz <mina86@mina86.com>
Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Signed-off-by: Andrzej Pietrasiewicz <andrzej.p@samsung.com>
Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
usb_gadget_ops :: udc_stop might be called with driver = NULL since
511f3c5326eabe1ece35202a404c24c0aeacc246
(usb: gadget: udc-core: fix a regression during gadget driver unbinding)
Because of that, 2nd times insmod goes fail.
This patch fixes it up.
Reported-by: Yusuke Goda <yusuke.goda.sx@renesas.com>
Signed-off-by: Kuninori Morimoto <kuninori.morimoto.gx@renesas.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
free_irq() expects the same device identity that was passed to
corresponding request_irq(), otherwise the IRQ is not freed.
Signed-off-by: Wei Yongjun <yongjun_wei@trendmicro.com.cn>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
|
When there is an error with the usb3_phy probe or absence, the error returned
is erroneously for usb2_phy.
Cc: <stable@vger.kernel.org>
Signed-off-by: Ruchika Kharwar <ruchika@ti.com>
Signed-off-by: Felipe Balbi <balbi@ti.com>
|
