Daniel Vetter [Fri, 15 Feb 2013 20:21:37 +0000 (21:21 +0100)]
drm: Don't set the plane->fb to NULL on successfull set_plane
We need to clear the local variable to get the refcounting right
(since the reference drm_mode_setplane holds is transferred to the
plane->fb pointer). But should be done _after_ we update the pointer.
Paulo Zanoni [Fri, 15 Feb 2013 15:36:27 +0000 (13:36 -0200)]
drm: don't add inferred modes for monitors that don't support them
If bit 0 of the features byte (0x18) is set to 0, then, according to
the EDID spec, "the display is non-continuous frequency (multi-mode)
and is only specified to accept the video timing formats that are
listed in Base EDID and certain Extension Blocks".
For more information, please see the EDID spec, check the notes of the
table that explains the "Feature Support" byte (18h) and also the
notes on the tables of the section that explains "Display Range Limits
& Additional Timing Description Definition (tag #FDh)".
Cc: stable@vger.kernel.org
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=45729 Reviewed-by: Alex Deucher <alexander.deucher@amd.com> Reviewed-by: Adam Jackson <ajax@redhat.com> Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Dave Airlie <airlied@redhat.com>
Paulo Zanoni [Tue, 19 Feb 2013 19:13:35 +0000 (16:13 -0300)]
drm/i915: clear the FPGA_DBG_RM_NOCLAIM bit at driver init
Otherwise, if the BIOS did anything wrong, our first I915_{WRITE,READ}
will give us "unclaimed register" messages.
V2: Even earlier.
V3: Move it to intel_early_sanitize_regs.
Bugzilla: http://bugs.freedesktop.org/show_bug.cgi?id=58897 Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Paulo Zanoni [Mon, 18 Feb 2013 22:00:21 +0000 (19:00 -0300)]
drm/i915: use FPGA_DBG for the "unclaimed register" checks
We plan to treat GEN7_ERR_INT as an interrupt, so use this register
for the checks inside I915_WRITE. This way we can have the best of
both worlds: the error message with a register address and the
V2: Split in 2 patches: one for the macro, one for changing the
register, as requested by Ben.
V3: Rebase.
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
Eric Dumazet [Tue, 19 Feb 2013 18:42:03 +0000 (10:42 -0800)]
ppp: set qdisc_tx_busylock to avoid LOCKDEP splat
If a qdisc is installed on a ppp device, its possible to get
a lockdep splat under stress, because nested dev_queue_xmit() can
lock busylock a second time (on a different device, so its a false
positive)
Avoid this problem using a distinct lock_class_key for ppp
devices.
Reported-by: Yanko Kaneti <yaneti@declera.com> Tested-by: Yanko Kaneti <yaneti@declera.com> Signed-off-by: Eric Dumazet <edumazet@google.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Cong Wang [Tue, 19 Feb 2013 02:47:05 +0000 (02:47 +0000)]
net: fix a build failure when !CONFIG_PROC_FS
When !CONFIG_PROC_FS dev_mcast_init() is not defined,
actually we can just merge dev_mcast_init() into
dev_proc_init().
Reported-by: Gao feng <gaofeng@cn.fujitsu.com> Cc: Gao feng <gaofeng@cn.fujitsu.com> Cc: "David S. Miller" <davem@davemloft.net> Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net>
Gao feng [Tue, 19 Feb 2013 00:43:10 +0000 (00:43 +0000)]
net: proc: fix build failed when procfs is not configured
commit d4beaa66add8aebf83ab16d2fde4e4de8dac36df
"net: proc: change proc_net_fops_create to proc_create"
uses proc_create to replace proc_net_fops_create, when
CONFIG_PROC isn't configured, some build error will
occurs.
net/packet/af_packet.c: In function 'packet_net_init':
net/packet/af_packet.c:3831:48: error: 'packet_seq_fops' undeclared (first use in this function)
net/packet/af_packet.c:3831:48: note: each undeclared identifier is reported only once for each function it appears in
There may be other build fails like above,this patch
change proc_create from function to macros when CONFIG_PROC
is not configured,just like what proc_net_fops_create did
before this commit.
Reported-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Gao feng <gaofeng@cn.fujitsu.com> Signed-off-by: David S. Miller <davem@davemloft.net>
====================
But this is wrong from all we can tell, we discussed this before
(Wei pointed to the discussion in an earlier reply). The core of
it is that the put here parallels the one in netbk_tx_err(), and
the one in xenvif_carrier_off() matches the get from
xenvif_connect() (which normally would be done on the path
coming through xenvif_disconnect()).
====================
Because the eld buffer can be simultaneously accessed from both
workqueue context (updating) and process context (kcontrol read),
we need to protect it with a mutex to guarantee consistency.
To avoid holding the mutex while reading the ELD info from the
codec, we introduce a temporary eld buffer.
Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
ALSA: hda - hdmi: ELD shouldn't be valid after unplug
Currently, eld_valid is never set to false, except at kernel module
load time. This patch makes sure that eld is no longer valid when
the cable is (hot-)unplugged.
Cc: stable@kernel.org Signed-off-by: David Henningsson <david.henningsson@canonical.com> Signed-off-by: Takashi Iwai <tiwai@suse.de>
Trond Myklebust [Tue, 19 Feb 2013 17:04:42 +0000 (12:04 -0500)]
NLM: Ensure that we resend all pending blocking locks after a reclaim
Currently, nlmclnt_lock will break out of the for(;;) loop when
the reclaimer wakes up the blocking lock thread by setting
nlm_lck_denied_grace_period. This causes the lock request to fail
with an ENOLCK error.
The intention was always to ensure that we resend the lock request
after the grace period has expired.
Harninder Rai [Tue, 19 Feb 2013 09:13:58 +0000 (14:43 +0530)]
powerpc/85xx: bsc9131 - Correct typo in SDHC device node
BSC9131RDB doesn't have SDHC enabled. As a result of this typo,
the node was not getting disabled from the device tree which was
leading to linux hang during bootup
Signed-off-by: Harninder Rai <harninder.rai@freescale.com> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
Ben Hutchings [Tue, 19 Feb 2013 00:24:26 +0000 (02:24 +0200)]
kbuild: Fix missing '\n' for NEW symbols in yes "" | make oldconfig >conf.new
According to Documentation/kbuild/kconfig.txt, the commands:
yes "" | make oldconfig >conf.new
grep "(NEW)" conf.new
should list the new config symbols with their default values.
However, currently there is no line break after each new symbol. When
kconfig is interactive the user will type a new-line at this point,
but when non-interactive kconfig must print it.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Reference: http://bugs.debian.org/636029
[regid23@nt1.in: Adjusted Ben's work to apply cleanly to this tree] Reported-and-tested-by: Regid Ichira <regid23@nt1.in> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Michal Marek <mmarek@suse.cz>
Mathias Krause [Tue, 5 Feb 2013 17:19:14 +0000 (18:19 +0100)]
crypto: user - fix empty string test in report API
The current test for empty strings fails because it is testing the
address of a field, not a pointer. So the test will always be true.
Test the first character in the string to not be null instead.
Mathias Krause [Tue, 5 Feb 2013 17:19:13 +0000 (18:19 +0100)]
crypto: user - fix info leaks in report API
Three errors resulting in kernel memory disclosure:
1/ The structures used for the netlink based crypto algorithm report API
are located on the stack. As snprintf() does not fill the remainder of
the buffer with null bytes, those stack bytes will be disclosed to users
of the API. Switch to strncpy() to fix this.
2/ crypto_report_one() does not initialize all field of struct
crypto_user_alg. Fix this to fix the heap info leak.
3/ For the module name we should copy only as many bytes as
module_name() returns -- not as much as the destination buffer could
hold. But the current code does not and therefore copies random data
from behind the end of the module name, as the module name is always
shorter than CRYPTO_MAX_ALG_NAME.
Also switch to use strncpy() to copy the algorithm's name and
driver_name. They are strings, after all.
Paulo Zanoni [Mon, 18 Feb 2013 22:00:26 +0000 (19:00 -0300)]
drm/i915: rename sdvox_reg to hdmi_reg on HDMI context
Some (but not all) of the HDMI registers can be used to control sDVO,
so those registers have two names. IMHO, when we're talking about
HDMI, we really should call the HDMI control register "hdmi_reg"
instead of "sdvox_reg", otherwise we'll just confuse people reading
our code (we now have platforms with HDMI but without SDVO). So now
"struct intel_hdmi" has a member called "hdmi_reg" instead of
"sdvox_reg".
Also, don't worry: "struct intel_sdvo" still has a member called
"sdvo_reg".
v2: Rebase (v1 was sent in May 2012).
Signed-off-by: Paulo Zanoni <paulo.r.zanoni@intel.com> Signed-off-by: Daniel Vetter <daniel.vetter@ffwll.ch>
projects / karo-tx-linux.git / log