dvb_usb_device_init calls the frontend_attach method of this driver which
uses vp7045_usb_ob. In order to have a buffer ready in vp7045_usb_op, it has to
be allocated before that happens.
Luckily we can use the whole private data as the buffer as it gets separately
allocated on the heap via kzalloc in dvb_usb_device_init and is thus apt for
use via usb_control_msg.
This fixes a
BUG: unable to handle kernel paging request at 0000000000001e78
reported by Tino Keitel and diagnosed by Dan Carpenter.
Cc: [email protected] # For v3.0 and upper
Tested-by: Tino Keitel <[email protected]>
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Tested-by: Malcolm Priestley <[email protected]>
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Signed-off-by: Florian Mickler <[email protected]>
Acked-by: Antti Palosaari <[email protected]>
Reviewed-by: Antti Palosaari <[email protected]>
Tested-by: Antti Palosaari <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Signed-off-by: Florian Mickler <[email protected]>
Acked-by: Antti Palosaari <[email protected]>
Reviewed-by: Antti Palosaari <[email protected]>
Tested-by: Antti Palosaari <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Signed-off-by: Florian Mickler <[email protected]>
Acked-by: Antti Palosaari <[email protected]>
Reviewed-by: Antti Palosaari <[email protected]>
Tested-by: Antti Palosaari <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
If we need a bigger buffer, we reallocte a new buffer and free the old
one.
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Note: This change is tested to compile only as I don't have the
hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Otherwise it is not obvious that vp702x_usb_in_op or vp702x_usb_out_op
will not interfere with any vp702x_usb_inout_op.
Note: This change is tested to compile only, as I don't have the
hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
This sets up a buffer and a mutex protecting that buffer in
the struct vp702x_device_state.
The definition of struct vp702x_device_state is moved into the header
in order to use the buffer also in the frontend.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
We need a state struct for the dvb_usb_device.
In order to reduce confusion we rename the vp702x_state struct.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
Some whitespace, one linebreak and one unneded variable
initialization...
Signed-off-by: Florian Mickler <[email protected]>
Cc: Patrick Boettcher <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Michael Krufky <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Igor M. Liplianin <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler <[email protected]>
Cc: Akihiro Tsukada <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
usb_control_msg initiates (and waits for completion of) a dma transfer using
the supplied buffer. That buffer thus has to be seperately allocated on
the heap.
In lib/dma_debug.c the function check_for_stack even warns about it:
WARNING: at lib/dma-debug.c:866 check_for_stack
Note: This change is tested to compile only, as I don't have the hardware.
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Mauro Carvalho Chehab <[email protected]>
If the requested device is already active, ignore the request.
This restores the original behaviour of the interface. The change was
probably an unintended side effect of
commit 66b37c6777 vga_switcheroo: split switching into two stages
which did not take into account to duplicate the !active check in the split-off
stage2.
Fix this by factoring that check out of stage1 into the debugfs_write routine.
References: https://bugzilla.kernel.org/show_bug.cgi?id=34252
Reported-by: Igor Murzov <[email protected]>
Tested-by: Igor Murzov <[email protected]>
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
In case !CONFIG_ACPI_NUMA and !CONFIG_AMD_NUMA gcc emits a warning
about the unused variable ret.
As that variable is in fact not needed I choose to remove it.
Signed-off-by: Florian Mickler <[email protected]>
LKML-Reference: <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
It is not obvious how to debug run-away workers.
These are some tips given by Tejun on lkml.
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Tejun Heo <[email protected]>
The module forgot to sometimes unregister some resources.
This fixes Bug #22882.
[Patch updated to 2.6.38-rc3 by Randy Dunlap.]
Tested-by: Randy Dunlap <[email protected]>
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Dave Airlie <[email protected]>
We should only claim that something is a cast if we did not encouter a
token before, that did set av_pending.
This fixes the operator * in the line below to be detected as binary (vs
unary).
kmalloc(sizeof(struct alphatrack_ocmd) * true_size, GFP_KERNEL);
Reported-by: Audun Hoem <[email protected]>
Signed-off-by: Florian Mickler <[email protected]>
Cc: Andy Whitcroft <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This is a first version of an interactive mode for
scripts/get_maintainer.pl.
It allows the user to interact with the script. Each cc candidate can be
selected and deselected and a shortlog of authored commits can be
displayed for each candidate.
The menu is displayed via STDERR, the end result is outputted to STDOUT.
This unusual mechanism allows using get_maintainer.pl in interactive mode
via git send-email --cc-cmd.
Signed-off-by: Joe Perches <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
iwl3945's scan_completed calls into the mac80211 stack which triggers a
warn on if there is no scan outstanding.
This can be avoided by not calling scan_completed but abort_scan in
iwl3945_request_scan in the done: branch of the function which is used
as an error out.
The done: branch seems to be an error-out branch, as, for example, if
iwl_is_ready(priv) returns false the done: branch is executed.
NOTE:
I'm not familiar with the driver at all.
I just quickly scanned as a reaction to
https://bugzilla.kernel.org/show_bug.cgi?id=17722
the users of scan_completed in the iwl3945 driver and noted the odd
discrepancy between the comment above this instance and the comment in
mac80211 scan_completed function.
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
The pm_qos_add_request call has to register the pm_qos request with the pm_qos
susbsystem before first use of the pm_qos request via
pm_qos_update_request.
As pm_qos changed to use plists there is no benefit in registering and
unregistering the pm_qos request on ifup/ifdown and thus we move the
registering into e1000_open and the unregistering in e1000_close.
This fixes the following warning:
[ 1.786060] WARNING: at kernel/pm_qos_params.c:264
pm_qos_update_request+0x28/0x54()
[ 1.786088] Hardware name: Latitude E6500
[ 1.787045] pm_qos_update_request() called for unknown object
[ 1.787966] Modules linked in:
[ 1.788940] Pid: 1, comm: swapper Not tainted 2.6.35-rc5-mmotm0719 #1
[ 1.790035] Call Trace:
[ 1.791121] [<ffffffff81037335>] warn_slowpath_common+0x80/0x98
[ 1.792205] [<ffffffff810373e1>] warn_slowpath_fmt+0x41/0x43
[ 1.793279] [<ffffffff81057c14>] pm_qos_update_request+0x28/0x54
[ 1.794347] [<ffffffff8134889e>] e1000_configure+0x421/0x459
[ 1.795393] [<ffffffff8134afbd>] e1000_open+0xbd/0x37c
[ 1.796436] [<ffffffff8105743a>] ? raw_notifier_call_chain+0xf/0x11
[ 1.797491] [<ffffffff8145f948>] __dev_open+0xae/0xe2
[ 1.798547] [<ffffffff8145f997>] dev_open+0x1b/0x49
[ 1.799612] [<ffffffff8146e36e>] netpoll_setup+0x84/0x259
[ 1.800685] [<ffffffff81b5037c>] init_netconsole+0xbc/0x21f
[ 1.801744] [<ffffffff81b5026c>] ? sir_wq_init+0x0/0x35
[ 1.802793] [<ffffffff81b502c0>] ? init_netconsole+0x0/0x21f
[ 1.803845] [<ffffffff810002ff>] do_one_initcall+0x7a/0x12f
[ 1.804885] [<ffffffff81b2ccae>] kernel_init+0x138/0x1c2
[ 1.805915] [<ffffffff81003554>] kernel_thread_helper+0x4/0x10
[ 1.806937] [<ffffffff81590e00>] ? restore_args+0x0/0x30
[ 1.807955] [<ffffffff81b2cb76>] ? kernel_init+0x0/0x1c2
[ 1.808958] [<ffffffff81003550>] ? kernel_thread_helper+0x0/0x10
[ 1.809958] ---[ end trace 84b562a00a60539e ]---
Signed-off-by: Florian Mickler <[email protected]>
Tested-by: Valdis Kletnieks <[email protected]>
Tested-by: Jeff Pieper <[email protected]>
Signed-off-by: Jeff Kirsher <[email protected]>
Signed-off-by: David S. Miller <[email protected]>
This changes the default of the option --git-all-signature-types to be
disabled by default.
The effect being, that only certain (currently Signed-Off-By:, Acked-by:
and Reviewed-By:) tags are used to get adresses of potential maintainers.
Motivated is this change by the desire to not 'spam' people unnecessary: A
Tested-By or a Reported-By is not ment as a hint that those people want
to/are able to review patches to the code in question.
In a quest to find resilient statistics for this i came up with this:
I produced a list of all the tag-signers not already covered with a
signed-off/acked/reviewed tag somewhere in the last year of git history.
Those were 650 addresses of "assumed non-developers".
And to check if those "assumed non-developers" are professional
testers/reporters worth cc'ing, i then counted their total appearences
in the git log:
469 were mentioned only once.
123 were mentioned twice.
38 three times
8 four times
5 six times
5 five times
1 eight times
1 fourteen times
I believe this supports my thesis, that the ''non-maintainer-tags'' are
not actively useful for patch-review. (except probably the guy mentioned
fourteen times...)
But of course one could also find arguments to poke holes in this
statistics, for example does this statistic not include code-locality: A
tested-by on a patch that touches some specific piece of code can be more
worth than a signed-off in another part of the tree.
But... let's play it safe and let's err on the "safe" side meaning to not
spam those people when in doubt. We already have the signed-off's and
Maintainers file. So this should be ok. And if need be, the maintainers
can always forward the patch.
[i probably could make a diploma thesis out of this changelog :)]
Signed-off-by: Florian Mickler <[email protected]>
Acked-by: Wolfram Sang <[email protected]>
Cc: Joe Perches <[email protected]>
Cc: Stefan Richter <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
Signed-off-by: Linus Torvalds <[email protected]>
This patch renames the (never officially released) sysfs-knobs
"blocked_hw" and "blocked_sw" to "hard" and "soft", as the hardware vs
software conotation is misleading.
It also gets rid of not needed locks around u32-read-access.
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This commit introduces two new sysfs knobs.
/sys/class/rfkill/rfkill[0-9]+/blocked_hw: (ro)
hardblock kill state
/sys/class/rfkill/rfkill[0-9]+/blocked_sw: (rw)
softblock kill state
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
This moves sysfs ABI info from Documentation/rfkill.txt to the
ABI subfolder and reformats it.
This also schedules the deprecated sysfs parts to be removed in
2012 (claim file) and 2014 (state file).
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Vbios will set lvds register correctly based on
current algorithm for lingle/dual Channel LVDS when
system boot, so we can accept this configuration
directly, regardless of LVDS enable status.
It fixed freedesktop.org bug #22262
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: Eric Anholt <[email protected]>
i915_gem_put_relocs_to_user returned an uninitialized value which
got returned to userspace. This caused libdrm in my setup to never
get out of a do{}while() loop retrying i915_gem_execbuffer.
result was hanging X, overheating of cpu and 2-3gb of logfile-spam.
This patch adresses the issue by
1. initializing vars in this file where necessary
2. correcting wrongly interpreted return values of copy_[from/to]_user
Signed-off-by: Florian Mickler <[email protected]>
[anholt: cleanups of unnecessary changes, consistency in APIs]
Signed-off-by: Eric Anholt <[email protected]>
Current setup with hal and NetworkManager will fail to work
without newest hal version with this config option disabled.
Although this will solve itself by time, at the moment it is
dishonest to say that we don't know any software that uses it,
if there are many many people relying on old hal versions.
Signed-off-by: Florian Mickler <[email protected]>
Signed-off-by: John W. Linville <[email protected]>
Florian Mickler