IF YOU WOULD LIKE TO GET AN ACCOUNT, please write an
email to Administrator. User accounts are meant only to access repo
and report issues and/or generate pull requests.
This is a purpose-specific Git hosting for
BaseALT
projects. Thank you for your understanding!
Только зарегистрированные пользователи имеют доступ к сервису!
Для получения аккаунта, обратитесь к администратору.
Move the SMBus device ID definitions of recent devices from pci_ids.h
to the i2c-i801.c driver file. They don't have to be shared, as they
are clearly identified and only used in this driver. In the future,
such IDs will go to i2c-i801 directly. This will make adding support
for new devices much faster and easier, as it will avoid cross-
subsystem patch sets and merge conflicts.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: Seth Heasley <seth.heasley@intel.com>
Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org>
The driver did not return an error if the call to hwmon_device_register failed.
Fix by returning the error reported from hwmon_device_register.
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
clkdev may incorrectly cause a clkdev entry with a NULL clk to return
-ENOENT. This is not the intention of this code; -ENOENT should only
be returned if the clock entry can not be found in the table. Fix
this.
Reported-by: Stephen Boyd <sboyd@codeaurora.org>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
Add support of pause frames advertise in mii_get_an. This provides all drivers
that use mii_ethtool_gset to represent their own and Link partner flow control
abilities in ethtool.
Signed-off-by: Artem Polyakov <artpol84@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Adam Jaremko <adam.jaremko@gmail.com>
Acked-by: Po-Yu Chuang <ratbert@faraday-tech.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Some newer Huawei devices (T-Mobile Rocket, others) have cdc-ether
compatible ports, so recognize and expose them.
Signed-off-by: Dan Williams <dcbw@redhat.com>
Acked-by: Oliver Neukum <oneukum@suse.de>
Signed-off-by: David S. Miller <davem@davemloft.net>
This oops was recently reported to me:
invalid opcode: 0000 [#1] SMP
last sysfs file:
/sys/devices/pci0000:00/0000:00:01.0/0000:01:0d.0/0000:02:05.0/device
CPU 1
Modules linked in: bnx2(+) sunrpc ipv6 dm_mirror dm_region_hash dm_log sg
microcode serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_piix4
shpchp ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
scsi_transport_sas radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core
dm_mod [last unloaded: bnx2]
Modules linked in: bnx2(+) sunrpc ipv6 dm_mirror dm_region_hash dm_log sg
microcode serio_raw amd64_edac_mod edac_core edac_mce_amd k8temp i2c_piix4
shpchp ext4 mbcache jbd2 sd_mod crc_t10dif mptsas mptscsih mptbase
scsi_transport_sas radeon ttm drm_kms_helper drm hwmon i2c_algo_bit i2c_core
dm_mod [last unloaded: bnx2]
Pid: 23900, comm: pidof Not tainted 2.6.32-130.el6.x86_64 #1 BladeCenter LS21
-[797251Z]-
RIP: 0010:[<ffffffffa058b270>] [<ffffffffa058b270>] 0xffffffffa058b270
RSP: 0018:ffff880002083e48 EFLAGS: 00010246
RAX: ffff880002083e90 RBX: ffff88007ccd4000 RCX: 0000000000000000
RDX: 0000000000000100 RSI: dead000000200200 RDI: ffff8800007b8700
RBP: ffff880002083ed0 R08: ffff88000208db40 R09: 0000022d191d27c8
R10: 0000000000000000 R11: 0000000000000000 R12: ffff8800007b9bc8
R13: ffff880002083e90 R14: ffff8800007b8700 R15: ffffffffa058b270
FS: 00007fbb3bcf7700(0000) GS:ffff880002080000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000001664a98 CR3: 0000000060395000 CR4: 00000000000006e0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process pidof (pid: 23900, threadinfo ffff8800007e8000, task ffff8800091c0040)
Stack:
ffffffff81079f77 ffffffff8109e010 ffff88007ccd5c20 ffff88007ccd5820
<0> ffff88007ccd5420 ffff8800007e9fd8 ffff8800007e9fd8 0000010000000000
<0> ffff88007ccd5020 ffff880002083e90 ffff880002083e90 ffffffff8102a00d
Call Trace:
<IRQ>
[<ffffffff81079f77>] ? run_timer_softirq+0x197/0x340
[<ffffffff8109e010>] ? tick_sched_timer+0x0/0xc0
[<ffffffff8102a00d>] ? lapic_next_event+0x1d/0x30
[<ffffffff8106f737>] __do_softirq+0xb7/0x1e0
[<ffffffff81092cc0>] ? hrtimer_interrupt+0x140/0x250
[<ffffffff81185f90>] ? filldir+0x0/0xe0
[<ffffffff8100c2cc>] call_softirq+0x1c/0x30
[<ffffffff8100df05>] do_softirq+0x65/0xa0
[<ffffffff8106f525>] irq_exit+0x85/0x90
[<ffffffff814e3340>] smp_apic_timer_interrupt+0x70/0x9b
[<ffffffff8100bc93>] apic_timer_interrupt+0x13/0x20
<EOI>
[<ffffffff81211ba5>] ? selinux_file_permission+0x45/0x150
[<ffffffff81262a75>] ? _atomic_dec_and_lock+0x55/0x80
[<ffffffff812050c6>] security_file_permission+0x16/0x20
[<ffffffff811861c1>] vfs_readdir+0x71/0xe0
[<ffffffff81186399>] sys_getdents+0x89/0xf0
[<ffffffff8100b172>] system_call_fastpath+0x16/0x1b
It occured during some stress testing, in which the reporter was repeatedly
removing and modprobing the bnx2 module while doing various other random
operations on the bnx2 registered net device. Noting that this error occured on
a serdes based device, we noted that there were a few ethtool operations (most
notably self_test and set_phys_id) that have execution paths that lead into
bnx2_setup_serdes_phy. This function is notable because it executes a mod_timer
call, which starts the bp->timer running. Currently bnx2 is setup to assume
that this timer only nees to be stopped when bnx2_close or bnx2_suspend is
called. Since the above ethtool operations are not gated on the net device
having been opened however, that assumption is incorrect, and can lead to the
timer still running after the module has been removed, leading to the oops above
(as well as other simmilar oopses).
Fix the problem by ensuring that the timer is stopped when pci_device_unregister
is called.
Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
Reported-by: Hushan Jia <hjia@redhat.com>
CC: Michael Chan <mchan@broadcom.com>
CC: "David S. Miller" <davem@davemloft.net>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:
"Received BA when not expected"
or (on older kernels):
"BA scd_flow 0 does not match txq_id 10"
This fix regression introduced in 2.6.35 during station management
code rewrite by:
commit 2a87c26bbe9587baeb9e56d3ce0b4971bd777643
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri Apr 30 11:30:45 2010 -0700
iwlwifi: use iwl_find_station less
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Need to use broadcast sta_id for management frames, otherwise we broke
BA session in the firmware and get messages like that:
"Received BA when not expected"
or (on older kernels):
"BA scd_flow 0 does not match txq_id 10"
This fix regression introduced in 2.6.35 during station management
code rewrite by:
commit 2a87c26bbe9587baeb9e56d3ce0b4971bd777643
Author: Johannes Berg <johannes.berg@intel.com>
Date: Fri Apr 30 11:30:45 2010 -0700
iwlwifi: use iwl_find_station less
Patch partially resolve:
https://bugzilla.kernel.org/show_bug.cgi?id=16691
However, there are still 11n performance problems on 4965 and 5xxx
devices that need to be investigated.
Cc: stable@kernel.org # 2.6.35+
Signed-off-by: Stanislaw Gruszka <sgruszka@redhat.com>
Acked-by: Johannes Berg <johannes@sipsolutions.net>
Acked-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Fix CI data transfer regression introduced by previous cleanup.
Signed-off-by: Oliver Endriss <o.endriss@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some v4l drivers currently don't initialize their struct v4l2_subdev
with zeros, and this is a problem since some of the v4l2 code expects
this. One example is the addition of internal_ops in commit 45f6f84,
after that we are at risk of random oopses with these drivers when code
in v4l2_device_register_subdev tries to dereference sd->internal_ops->*,
as can be shown by the report at http://bugs.launchpad.net/bugs/745213
and analysis of its crash at https://lkml.org/lkml/2011/4/1/168
Use kzalloc within problematic drivers to ensure we have a zeroed struct
v4l2_subdev.
BugLink: http://bugs.launchpad.net/bugs/745213
Cc: <stable@kernel.org>
Signed-off-by: Herton Ronaldo Krzesinski <herton.krzesinski@canonical.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The following is a patch to avoid a kernel oops when running rmmod
saa7134 on kernel 2.6.27.1. The change is as suggested by mchehab on
irc.freenode.org
Signed-off-by: Hussam Al-Tayeb <ht990332@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We must remove all files we created, even in error cases.
Fixes second part of kernel bug #34072:
https://bugzilla.kernel.org/show_bug.cgi?id=34072
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
Recent Xeon processor thermal sensors are supported by the coretemp
driver and not the adm1021 driver. Only one old generation of Xeon
processors (the first Netburst ones) are supported by the adm1021
driver.
Reported-by: Darren Hart <dvhart@linux.intel.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Acked-by: Guenter Roeck <guenter.roeck@ericsson.com>
This patch adds support for ADT7461A and NCT1008 to the lm90 driver.
Both chips have identical functionality and report the same manufacturing ID
and device ID values.
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
Signed-off-by: Jean Delvare <khali@linux-fr.org>
The imon_ir_change_protocol function gets called two different ways, one
way is from rc_register_device, for initial protocol selection/setup,
and the other is via a userspace-initiated protocol change request,
either by direct sysfs prodding or by something like ir-keytable.
In the rc_register_device case, the imon context lock is already held,
but when initiated from userspace, it is not, so we must acquire it,
prior to calling send_packet, which requires that the lock is held.
Without this change, there's an easily reproduceable deadlock when
another function calls send_packet (such as either of the display write
fops) after a userspace-initiated change_protocol.
With a lock-debugging-enabled kernel, I was getting this:
[ 15.014153] =====================================
[ 15.015048] [ BUG: bad unlock balance detected! ]
[ 15.015048] -------------------------------------
[ 15.015048] ir-keytable/773 is trying to release lock (&ictx->lock) at:
[ 15.015048] [<ffffffff814c6297>] mutex_unlock+0xe/0x10
[ 15.015048] but there are no more locks to release!
[ 15.015048]
[ 15.015048] other info that might help us debug this:
[ 15.015048] 2 locks held by ir-keytable/773:
[ 15.015048] #0: (&buffer->mutex){+.+.+.}, at: [<ffffffff8119d400>] sysfs_write_file+0x3c/0x144
[ 15.015048] #1: (s_active#87){.+.+.+}, at: [<ffffffff8119d4ab>] sysfs_write_file+0xe7/0x144
[ 15.015048]
[ 15.015048] stack backtrace:
[ 15.015048] Pid: 773, comm: ir-keytable Not tainted 2.6.38.4-20.fc15.x86_64.debug #1
[ 15.015048] Call Trace:
[ 15.015048] [<ffffffff81089715>] ? print_unlock_inbalance_bug+0xca/0xd5
[ 15.015048] [<ffffffff8108b35c>] ? lock_release_non_nested+0xc1/0x263
[ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<ffffffff8108b67b>] ? lock_release+0x17d/0x1a4
[ 15.015048] [<ffffffff814c6229>] ? __mutex_unlock_slowpath+0xc5/0x125
[ 15.015048] [<ffffffff814c6297>] ? mutex_unlock+0xe/0x10
[ 15.015048] [<ffffffffa02964b6>] ? send_packet+0x1c9/0x264 [imon]
[ 15.015048] [<ffffffff8108b376>] ? lock_release_non_nested+0xdb/0x263
[ 15.015048] [<ffffffffa0296731>] ? imon_ir_change_protocol+0x126/0x15e [imon]
[ 15.015048] [<ffffffffa024a334>] ? store_protocols+0x1c3/0x286 [rc_core]
[ 15.015048] [<ffffffff81326e4e>] ? dev_attr_store+0x20/0x22
[ 15.015048] [<ffffffff8119d4cc>] ? sysfs_write_file+0x108/0x144
...
The original report that led to the investigation was the following:
[ 1679.457305] INFO: task LCDd:8460 blocked for more than 120 seconds.
[ 1679.457307] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 1679.457309] LCDd D ffff88010fcd89c8 0 8460 1 0x00000000
[ 1679.457312] ffff8800d5a03b48 0000000000000082 0000000000000000 ffff8800d5a03fd8
[ 1679.457314] 00000000012dcd30 fffffffffffffffd ffff8800d5a03fd8 ffff88010fcd86f0
[ 1679.457316] ffff8800d5a03fd8 ffff8800d5a03fd8 ffff88010fcd89d0 ffff8800d5a03fd8
[ 1679.457319] Call Trace:
[ 1679.457324] [<ffffffff810ff1a5>] ? zone_statistics+0x75/0x90
[ 1679.457327] [<ffffffff810ea907>] ? get_page_from_freelist+0x3c7/0x820
[ 1679.457330] [<ffffffff813b0a49>] __mutex_lock_slowpath+0x139/0x320
[ 1679.457335] [<ffffffff813b0c41>] mutex_lock+0x11/0x30
[ 1679.457338] [<ffffffffa0d54216>] display_open+0x66/0x130 [imon]
[ 1679.457345] [<ffffffffa01d06c0>] usb_open+0x180/0x310 [usbcore]
[ 1679.457349] [<ffffffff81143b3b>] chrdev_open+0x1bb/0x2d0
[ 1679.457350] [<ffffffff8113d93d>] __dentry_open+0x10d/0x370
[ 1679.457352] [<ffffffff81143980>] ? chrdev_open+0x0/0x2d0
...
Bump the driver version here so its easier to tell if people have this
locking fix or not, and also make locking during probe easier to follow.
CC: stable@kernel.org
Reported-by: Benjamin Hodgetts <ben@xnode.org>
Signed-off-by: Jarod Wilson <jarod@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
pfault, dasd diag and virtio all use the same external interrupt number.
The respective interrupt handlers decide by the subcode if they are
meant to handle the interrupt.
Counting is currently done before looking at the subcode which means
each handler counts an interrupt even if it is not handling it.
Fix this by moving the kstat code after the code which looks at the
subcode.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
Signed-off-by: Martin Schwidefsky <schwidefsky@de.ibm.com>
cdrom_open() called check_disk_change() after the rest of open path
succeeded which leads to the following bizarre behavior.
* After media change, if the device opened without O_NONBLOCK,
open_for_data() naturally fails with -ENOMEDIA and
check_disk_change() is never called. The media is known to be gone
and the open failure makes it obvious to the userland but device
invalidation never happens.
* But if the device is opened with O_NONBLOCK, all the checks are
bypassed and cdrom_open() doesn't notice that the media is not there
and check_disk_change() is called and invalidation happens.
There's nothing to be gained by avoiding calling check_disk_change()
on open failure. Common cases end up calling check_disk_change()
anyway. All we get is inconsistent behavior.
Fix it by moving check_disk_change() invocation to the top of
cdrom_open() so that it always gets called regardless of how the rest
of open proceeds.
Stable: 2.6.38
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Amit Shah <amit.shah@redhat.com>
Tested-by: Amit Shah <amit.shah@redhat.com>
Cc: stable@kernel.org
Signed-off-by: Jens Axboe <jaxboe@fusionio.com>
* 'drm-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/airlied/drm-2.6:
drm/i915: restore only the mode of this driver on lastclose (v2)
drm/radeon/kms: add info query for tile pipes
drm/radeon/kms: add missing safe regs for 6xx/7xx
drm: select FRAMEBUFFER_CONSOLE_PRIMARY if we have FRAMEBUFFER_CONSOLE
Resubmit interrupt URB if device is open. Use a flag set in
usbnet_open() to determine this state. Also kill and free
interrupt URB in usbnet_disconnect().
[Rebased off git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git]
Signed-off-by: Paul Stewart <pstew@chromium.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
commit 5ed540aecc2aae92d5c97b9a9306a5bf88ad5574 change the led behavior
for iwlwifi driver; the side effect cause led blink all the time.
Modify the led blink table to fix this problem
Signed-off-by: Wey-Yi Guy <wey-yi.w.guy@intel.com>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
We call rtc_read_alarm from rtc_device_register, so it is important
that the rtc device is fully initialized prior to registration.
rtc-max8925 sets drvdata after register, so the rtc_read_alarm code
dereferences a NULL pointer.
Call dev_set_drvdata before rtc_device_register.
[ jstultz/tglx: Massaged commit message ]
Signed-off-by: Zhangfei Gao <zhangfei.gao@marvell.com>
Cc: Alessandro Zummo <a.zummo@towertech.it>
Link: http://lkml.kernel.org/r/%3C1303929869-25249-1-git-send-email-john.stultz%40linaro.org%3E
Signed-off-by: John Stultz <john.stultz@linaro.org>
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Don't report BTN_TOUCH until we've got data as some less robust applications
can be confused by getting a touch event by itself and it doesn't seem
unreasonable for them to expect coordinates along with a touch.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
This allows maximum flexibility for configuring the direct GPIO based
interrupts.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
If the WM831x pen down and data IRQs run in parallel it is possible for the
data and pen down IRQs to deadlock themselves as one is part way through
disabling its operation while the other is part way through enabling. Fix
this by always disabling the pen down interrupt while data is active and
vice versa. When a changeover is required we disable the IRQ that is to
be stopped then schedule work that will enable the new IRQ.
We need to handle the data flow in the data IRQ as the readback from the
device needs to be ordered correctly with the IRQ for robust operation.
This also fixes an issue when using the built in IRQs due to enable_irq()
not being valid from interrupt context on an interrupt controller with bus
operations like the built in IRQ controller - this issue may also have
affected other interrupt controllers. We can't rely on having the data
and pen down IRQs available via GPIOs on the CPU on every system.
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
It seems that under certain circumstances the sdhci_tasklet_finish()
call can be entered with mrq set to NULL, causing the system to crash
with a NULL pointer de-reference.
Seen on S3C6410 system. Based on a patch by Dimitris Papastamos.
Reported-by: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
It seems that under certain circumstances that the sdhci_tasklet_finish()
call can be entered with mrq->cmd set to NULL, causing the system to crash
with a NULL pointer de-reference.
Unable to handle kernel NULL pointer dereference at virtual address 00000000
PC is at sdhci_tasklet_finish+0x34/0xe8
LR is at sdhci_tasklet_finish+0x24/0xe8
Seen on S3C6410 system.
Signed-off-by: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
The aggressive clock gating for TMIO MMC patch has broken switching
interface power on, using MFD or platform callbacks. Restore the
ios->power_mode == MMC_POWER_UP && ios->clock == 0 case handling.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Chris Ball <cjb@laptop.org>
Currently there is a race in the MMC core between a card-detect
rescan work and the clock-gating work, scheduled from a command
completion. Fix it by removing the dedicated clock-gating mutex
and using the MMC standard locking mechanism instead.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Cc: Simon Horman <horms@verge.net.au>
Cc: Magnus Damm <damm@opensource.se>
Acked-by: Linus Walleij <linus.walleij@linaro.org>
Cc: <stable@kernel.org>
Signed-off-by: Chris Ball <cjb@laptop.org>
Either OMAP_MMC_STAT_CARD_ERR or OMAP_MMC_STAT_END_OF_CMD might fire
if there is no host->cmd pointer.
Check for a valid host->cmd pointer before calling mmc_omap_cmd_done().
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Tony Lindgren <tony@atomide.com>
Signed-off-by: Chris Ball <cjb@laptop.org>
Fixes a cosmetic bug that affects printk() for SD-combo cards.
Reported-by: Prashanth Bhat <prashanth.bhat@manipal.net>
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
Signed-off-by: Chris Ball <cjb@laptop.org>
If pci_ioremap_bar() fails during probe, we "goto release;" and free the
host, but then we return 0 -- which tells sdhci_pci_probe() that the probe
succeeded. Since we think the probe succeeded, when we unload sdhci we'll
go to sdhci_pci_remove_slot() and it will try to dereference slot->host,
which is now NULL because we freed it in the error path earlier.
The patch simply sets ret appropriately, so that sdhci_pci_probe() will
detect the failure immediately and bail out.
Signed-off-by: Chris Ball <cjb@laptop.org>
Cc: <stable@kernel.org>
* 'v4l_for_linus' of git://git.kernel.org/pub/scm/linux/kernel/git/mchehab/linux-2.6: (42 commits)
[media] media: vb2: correct queue initialization order
[media] media: vb2: fix incorrect v4l2_buffer->flags handling
[media] s5p-fimc: Add support for the buffer timestamps and sequence
[media] s5p-fimc: Fix bytesperline and plane payload setup
[media] s5p-fimc: Do not allow changing format after REQBUFS
[media] s5p-fimc: Fix FIMC3 pixel limits on Exynos4
[media] tda18271: update tda18271c2_rf_cal as per NXP's rev.04 datasheet
[media] tda18271: update tda18271_rf_band as per NXP's rev.04 datasheet
[media] tda18271: fix bad calculation of main post divider byte
[media] tda18271: prog_cal and prog_tab variables should be s32, not u8
[media] tda18271: fix calculation bug in tda18271_rf_tracking_filters_init
[media] omap3isp: queue: Don't corrupt buf->npages when get_user_pages() fails
[media] v4l: Don't register media entities for subdev device nodes
[media] omap3isp: Don't increment node entity use count when poweron fails
[media] omap3isp: lane shifter support
[media] omap3isp: ccdc: support Y10/12, 8-bit bayer fmts
[media] media: add missing 8-bit bayer formats and Y12
[media] v4l: add V4L2_PIX_FMT_Y12 format
cx23885: Fix stv0367 Kconfig dependency
[media] omap3isp: Use isp xclk defines
...
Fix up trivial conflict (spelink errurs) in drivers/media/video/omap3isp/isp.c
i915 calls the panic handler function on last close to reset the modes,
however this is a really bad idea for multi-gpu machines, esp shareable
gpus machines. So add a new entry point for the driver to just restore
its own fbcon mode.
v2: move code into fb helper, fix panic code to block mode change on
powered off GPUs.
[airlied: this hits drm core and I wrote it and it was reviewed on intel-gfx
so really I signed it off twice ;-).]
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Signed-off-by: Dave Airlie <airlied@redhat.com>
Multi-gpu/switcheroo relies on this option to get the console on the
correct GPU at bootup, some distros enable it but it seems some get
it wrong.
cc: stable@kernel.org
Signed-off-by: Dave Airlie <airlied@redhat.com>
