em28xx uses core assisted locking, so it shouldn't use .ioctl.
The .ioctl callback was replaced by .unlocked_ioctl for video nodes,
but not for radio nodes. This is now corrected.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It seems that cx88 and ivtv use wm8775 on some different modes. The
patch that added support for a board with wm8775 broke ivtv boards with
this device. As we're too close to release 2.6.37, let's just revert
it.
Reported-by: Andy Walls <awalls@md.metrocast.net>
Reported-by: Eric Sharkey <eric@lisaneric.org>
Reported-by: Auric <auric@aanet.com.au>
Reported by: David Gesswein <djg@pdp8online.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch fixes a regression that crept into 2.6.36.
The volume control scale in the cx25840 driver has an unusual mapping
from register values to v4l2 volume control values. Enforce the mapping
limits, so that the default volume control setting does not fall out of
bounds to prevent the cx25840 module device probe from failing.
Signed-off-by: Andy Walls <awalls@md.metrocast.net>
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This lets drivers, optionally using the dmaengine, build with DMA_ENGINE
unselected.
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
use mv_xor_slot_cleanup() instead of __mv_xor_slot_cleanup() as the former function
aquires the spin lock that needed to protect the drivers data.
Cc: <stable@kernel.org>
Signed-off-by: Saeed Bishara <saeed@marvell.com>
Signed-off-by: Dan Williams <dan.j.williams@intel.com>
This patch fixes below build error by adding the missing asm/memory.h,
which is needed for arch_is_coherent().
$ make pxa3xx_defconfig; make
CC init/do_mounts_rd.o
In file included from include/linux/list_bl.h:5,
from include/linux/rculist_bl.h:7,
from include/linux/dcache.h:7,
from include/linux/fs.h:381,
from init/do_mounts_rd.c:3:
include/linux/bit_spinlock.h: In function 'bit_spin_unlock':
include/linux/bit_spinlock.h:61: error: implicit declaration of function 'arch_is_coherent'
make[1]: *** [init/do_mounts_rd.o] Error 1
make: *** [init] Error 2
Signed-off-by: Axel Lin <axel.lin@gmail.com>
Acked-by: Peter Huewe <peterhuewe@gmx.de>
Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
The error message 'NMI watchdog failed to create perf event...'
does not make it clear that this is a fatal error for the
watchdog. It also currently prints the error value as a
pointer, rather than extracting the error code with PTR_ERR().
Fix that.
Add a note to the description of the 'nowatchdog' kernel
parameter to associate it with this message.
Reported-by: Cesare Leonardi <celeonar@gmail.com>
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Cc: 599368@bugs.debian.org
Cc: 608138@bugs.debian.org
Cc: Don Zickus <dzickus@redhat.com>
Cc: Frederic Weisbecker <fweisbec@gmail.com>
Cc: <stable@kernel.org> # .37.x and later
LKML-Reference: <1294009362.3167.126.camel@localhost>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
The owner field was removed from struct attribute in
6fd69dc578, so don't assign it anymore.
Signed-off-by: Maurus Cuelenaere <mcuelenaere@gmail.com>
Signed-off-by: Guenter Roeck <guenter.roeck@ericsson.com>
* 'rc-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/mmarek/kbuild-2.6:
kconfig: fix undesirable side effect of adding "visible" menu attribute
isr_ack is never initialized. So, until the first PIC reset, interrupts
may fail to be injected. This can cause Windows XP to fail to boot, as
reported in the fallout from the fix to
https://bugzilla.kernel.org/show_bug.cgi?id=21962.
Reported-and-tested-by: Nicolas Prochazka <prochazka.nicolas@gmail.com>
Signed-off-by: Avi Kivity <avi@redhat.com>
The earlier call to atm_dev_lookup increases the reference count of dev,
so decrease it on the way out.
The semantic match that finds this problem is as follows:
(http://coccinelle.lip6.fr/)
// <smpl>
@@
expression x, E;
constant C;
@@
x = atm_dev_lookup(...);
... when != false x != NULL
when != true x == NULL
when != \(E = x\|x = E\)
when != atm_dev_put(dev);
*return -C;
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit 56543af "starfire: use BUILD_BUG_ON for netdrv_addr_t" revealed
that the preprocessor condition used to find the size of dma_addr_t
yielded the wrong result for some architectures and configurations.
This was kluged for 64-bit PowerPC in commit 3e502e6 by adding yet
another case to the condition. However, 64-bit MIPS configurations
are not detected reliably either.
This should be fixed by using CONFIG_ARCH_DMA_ADDR_T_64BIT, but that
isn't yet defined everywhere it should be.
Signed-off-by: Ben Hutchings <ben@decadent.org.uk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Besides -ETIMEDOUT and -EINTR, pci_read_vpd may return other error
values like -ENODEV or -EINVAL which are ignored due to the buggy
check, but the data are not read from VPD anyway and this is checked
subsequently with at most 3 needless loop iterations. This does not
show up as a runtime bug.
CC: Matt Carlson <mcarlson@broadcom.com>
CC: Michael Chan <mchan@broadcom.com>
Signed-off-by: David Sterba <dsterba@suse.cz>
Signed-off-by: David S. Miller <davem@davemloft.net>
We are leaking memory in drivers/net/cnic.c::cnic_alloc_uio_rings() if
either of the calls to dma_alloc_coherent() fail. This patch fixes it by
freeing both the memory allocated with kzalloc() and memory allocated with
previous calls to dma_alloc_coherent() when there's a failure.
Thanks to Joe Perches <joe@perches.com> for suggesting a better
implementation than my initial version.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Michael Chan <mchan@broadcom.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hi,
In drivers/isdn/gigaset/capi.c::do_disconnect_req() we will leak the
memory allocated (with kmalloc) to 'b3cmsg' if the call to alloc_skb()
fails.
...
b3cmsg = kmalloc(sizeof(*b3cmsg), GFP_KERNEL);
allocation here ------^
if (!b3cmsg) {
dev_err(cs->dev, "%s: out of memory\n", __func__);
send_conf(iif, ap, skb, CAPI_MSGOSRESOURCEERR);
return;
}
capi_cmsg_header(b3cmsg, ap->id, CAPI_DISCONNECT_B3, CAPI_IND,
ap->nextMessageNumber++,
cmsg->adr.adrPLCI | (1 << 16));
b3cmsg->Reason_B3 = CapiProtocolErrorLayer1;
b3skb = alloc_skb(CAPI_DISCONNECT_B3_IND_BASELEN, GFP_KERNEL);
if (b3skb == NULL) {
dev_err(cs->dev, "%s: out of memory\n", __func__);
send_conf(iif, ap, skb, CAPI_MSGOSRESOURCEERR);
return;
leak here ------^
...
This leak is easily fixed by just kfree()'ing the memory allocated to
'b3cmsg' right before we return. The following patch does that.
Signed-off-by: Jesper Juhl <jj@chaosbits.net>
Acked-by: Tilman Schmidt <tilman@imap.cc>
Signed-off-by: David S. Miller <davem@davemloft.net>
Since the socket address is just being used as a unique identifier, its
inode number is an alternative that does not leak potentially sensitive
information.
CC-ing stable because MITRE has assigned CVE-2010-4565 to the issue.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Acked-by: Oliver Hartkopp <socketcan@hartkopp.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
* 'drm-intel-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/ickle/drm-intel:
drm/i915/dvo: Report LVDS attached to ch701x as connected
Revert "drm/i915/bios: Reverse order of 100/120 Mhz SSC clocks"
drm/i915: Verify Ironlake eDP presence on DP_A using the capability fuse
drm/i915, intel_ips: When i915 loads after IPS, make IPS relink to i915.
drm/i915/sdvo: Add hdmi connector properties after initing the connector
drm/i915: Set the required VFMUNIT clock gating disable on Ironlake.
This reverts commit 7e24cce38a because it
was never appropriate for mainline.
Do not check for init flag before starting I/O - zram module is unusable
without this fix.
The oops mentioned in the reverted commit message was actually a problem
only with the zram version as present in project's own repository where
we allocate struct zram_stats_cpu upon device initialization. OTOH, In
mainline/staging version of zram, we allocate struct stats upfront, so
this oops cannot happen in mainline version.
Checking for init_done flag in zram_make_request() results in a *no-op*
for any I/O operation since we simply always return success. This flag
is actually set when the first write occurs on a zram disk which
triggers its initialization.
Bug report: https://bugzilla.kernel.org/show_bug.cgi?id=25722
Reported-by: Dennis Jansen <dennis.jansen@web.de>
Signed-off-by: Nitin Gupta <ngupta@vflare.org>
Cc: Anton Blanchard <anton@samba.org>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'merge-spi' of git://git.secretlab.ca/git/linux-2.6:
spi/m68knommu: Coldfire QSPI platform support
spi/omap2_mcspi.c: Force CS to be in inactive state after off-mode transition
At __mem_cgroup_try_charge(), VM_BUG_ON(!mm->owner) is checked.
But as commented in mem_cgroup_from_task(), mm->owner can be NULL
in some racy case. This check of VM_BUG_ON() is bad.
A possible story to hit this is at swapoff()->try_to_unuse(). It passes
mm_struct to mem_cgroup_try_charge_swapin() while mm->owner is NULL. If we
can't get proper mem_cgroup from swap_cgroup information, mm->owner is used
as charge target and we see NULL.
Cc: Daisuke Nishimura <nishimura@mxp.nes.nec.co.jp>
Cc: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com>
Reported-by: Hugh Dickins <hughd@google.com>
Reported-by: Thomas Meyer <thomas@m3y3r.de>
Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com>
Reviewed-by: Balbir Singh <balbir@linux.vnet.ibm.com>
Signed-off-by: Hugh Dickins <hughd@google.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Mostly inspired by all the recent BKL removal changes, but a lot of older
updates also weren't properly recorded.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
As we have already detected something attached to the chip during
initialisation, always report the LVDS connector status as connected
during probing.
Signed-off-by: Chris Wilson <chris@chris-wilson.co.uk>
Sjoerd Simons reports that, without using position_fix=1, recording
experiences overruns. Work around that by applying the LPIB quirk
for his hardware.
Reported-and-tested-by: Sjoerd Simons <sjoerd@debian.org>
Cc: <stable@kernel.org>
Signed-off-by: Daniel T Chen <crimsun@ubuntu.com>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
The load_mixer_volumes() function, which can be triggered by
unprivileged users via the SOUND_MIXER_SETLEVELS ioctl, is vulnerable to
a buffer overflow. Because the provided "name" argument isn't
guaranteed to be NULL terminated at the expected 32 bytes, it's possible
to overflow past the end of the last element in the mixer_vols array.
Further exploitation can result in an arbitrary kernel write (via
subsequent calls to load_mixer_volumes()) leading to privilege
escalation, or arbitrary kernel reads via get_mixer_levels(). In
addition, the strcmp() may leak bytes beyond the mixer_vols array.
Signed-off-by: Dan Rosenberg <drosenberg@vsecurity.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Takashi Iwai <tiwai@suse.de>
After grabbing a msg from the msgq, the mcfqspi_work function calls
list_del_init on the mcfqspi->msgq which unintentionally deletes the rest
of the list before it can be processed. If qspi call was made using
spi_sync, this can result in a process hang.
Signed-off-by: Jate Sujjavanich <jsujjavanich@syntech-fuelmaster.com>
Acked-by: Steven King <sfking@fdwdc.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
This lead to non-selected, non-user-selectable options to be written
out to .config. This is not only pointless, but also preventing the
user to be prompted should any of those options eventually become
visible (e.g. by de-selecting the *_AUTO options the "visible"
attribute was added for.
Furthermore it is quite logical for the "visible" attribute of a menu
to control the visibility of all contained prompts, which is what the
patch does.
Signed-off-by: Jan Beulich <jbeulich@novell.com>
Signed-off-by: Michal Marek <mmarek@suse.cz>
When SPI wake up from OFF mode, CS is in the wrong state: force it to the
inactive state.
During the system life, I monitored the CS behavior using a oscilloscope.
I also activated debug in omap2_mcspi, so I saw when driver disable the clocks
and restore context when device is not used.Each time the CS was in the correct
state. It was only when system was put suspend to ram with off-mode activated
that on resume the CS was in wrong state( ie activated).
Changelog:
* Change from v1 to v2:
- Rebase on linus/master (after 2.6.37-rc1)
- Do some clean-up and fix indentation on both patches
- Add more explanations for patch 2
* Change from v2 to v3:
- Use directly resume function of spi_master instead of using function
- from spi_device as Grant Likely pointed it out.
- Force this transition explicitly for each CS used by a device.
* Change from v3 to v4:
- Patch clean-up according to Kevin Hilman and checkpatch.
- Now force CS to be in inactive state only if it was inactive when it was
suspended.
* Change from v4 to v5:
- Rebase on linus/master (after 2.6.37-rc3)
- Collapse some lines as pointed by Grant Likely
- Fix a spelling
* Change from v5 to v6:
- Rebase on linus/master (after 2.6.37-rc7)
- Use CONFIG_SUSPEND instead of CONFIG_PM
- Didn't use legacy PM methods anymore. Instead, add a struct dev_pm_ops and
add the resume method there.
- Fix multi-line comment style
* Change from v6 to v7:
- Rebase on linus/master (after 2.6.37-rc8)
- Drop an extra line
Signed-off-by: Gregory CLEMENT <gregory.clement@free-electrons.com>
Acked-by: David Brownell <dbrownell@users.sourceforge.net>
Reviewed-by: Kevin Hilman <khilman@deeprootsystems.com>
Signed-off-by: Grant Likely <grant.likely@secretlab.ca>
When racing on adding into user cache, the new allocated from mm slab
is freed without putting user namespace.
Since the user namespace is already operated by getting, putting has
to be issued.
Signed-off-by: Hillf Danton <dhillf@gmail.com>
Acked-by: Serge Hallyn <serge@hallyn.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We use the physical address instead of the base gfn for the four
PAE page directories we use in unpaged mode. When the guest accesses
an address above 1GB that is backed by a large host page, a BUG_ON()
in kvm_mmu_set_gfn() triggers.
Resolves: https://bugzilla.kernel.org/show_bug.cgi?id=21962
Reported-and-tested-by: Nicolas Prochazka <prochazka.nicolas@gmail.com>
KVM-Stable-Tag.
Signed-off-by: Avi Kivity <avi@redhat.com>
* 'perf-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
ring_buffer: Off-by-one and duplicate events in ring_buffer_read_page
* 'x86-fixes-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip:
x86/microcode: Fix double vfree() and remove redundant pointer checks before vfree()
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm8753 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Furthermore the generic cache uses zero-based numbering while the wm8753 cache
uses one-based numbering.
Thus we end up with two from each other incoherent caches, which leads to undefined
behaviour and crashes.
This patch fixes the issue by changing the wm8753 driver to use the generic
register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm9090 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the wm9090 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm8962 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the wm8962 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm8955 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the wm8955 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm8904 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the wm8904 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Ian Lartey <ian@opensource.wolfsonmicro.com>
Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm8741 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the wm8741 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Ian Lartey <ian@opensource.wolfsonmicro.com>
Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the wm8523 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the wm8523 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Ian Lartey <ian@opensource.wolfsonmicro.com>
Cc: Dimitris Papastamos <dp@opensource.wolfsonmicro.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The multi-component patch(commit f0fba2ad1) moved the allocation of the
register cache from the driver to the ASoC core. Most drivers where adjusted to
this, but the max98088 driver still uses its own register cache for its
private functions, while functions from the ASoC core use the generic cache.
Thus we end up with two from each other incoherent caches, which can lead to
undefined behaviour.
This patch fixes the issue by changing the max98088 driver to use the
generic register cache in its private functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Cc: Peter Hsiang <Peter.Hsiang@maxim-ic.com>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
Some codec drivers do not initialize the control_type field in their private
device struct, but still use it when calling snd_soc_codec_set_cache_io.
This patch fixes the issue by properly initializing it in the drivers probe
functions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com>
Cc: stable@kernel.org (for 2.6.37 only)
The intent here was to test if the allocation failed but we tested
"SharedMemSize" instead of "SharedMemAddr" by mistake.
Signed-off-by: Dan Carpenter <error27@gmail.com>
Reviewed-by: Jiri Pirko <jpirko@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Linux would not connect to other router running old version Cisco IOS (12.0).
This is most likely a bug in that version of IOS, since it is fixed
in later versions. As a workaround this patch allows a module parameter
to be set to disable compressing the protocol ID.
See: https://bugzilla.vyatta.com/show_bug.cgi?id=3979
RFC 1990 allows an implementation to formulate MP fragments as if protocol
compression had been negotiated. This allows us to always send compressed
protocol IDs. But some implementations don't accept MP fragments with
compressed protocol IDs. This parameter allows us to interoperate with
them. The default value of the configurable parameter is the same as the
current behavior: protocol compression is enabled. If protocol compression
is disabled we will not send compressed protocol IDs.
This is based on an earlier patch by Bob Gilligan (using a sysctl).
Module parameter is writable to allow for enabling even if ppp
is already loaded for other uses.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
Acked-by: Paul Mackerras <paulus@samba.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
This patch avoids disabling the vlan flags using ethtool.
Signed-off-by: Breno Leitao <leitao@linux.vnet.ibm.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
A race exists when initializing ueagle-atm devices where the generic atm
device may not yet be created before the driver attempts to initialize
it's PHY signal state, which checks whether the atm device has been
created or not. This often causes the sysfs 'carrier' attribute to be
'1' even though no signal has actually been found.
uea_probe
usbatm_usb_probe
driver->bind (uea_bind)
uea_boot
kthread_run(uea_kthread) uea_kthread
usbatm_atm_init uea_start_reset
atm_dev_register UPDATE_ATM_SIGNAL
UPDATE_ATM_SIGNAL checks whether the ATM device has been created and if
not, will not update the PHY signal state. Because of the race that
does not always happen in time, and the PHY signal state remains
ATM_PHY_SIG_FOUND even though no signal exists.
To fix the race, just create the kthread during initialization, and only
after initialization is complete, start the thread that reboots the
device and initializes PHY state.
[ 3030.490931] uea_probe: calling usbatm_usb_probe
[ 3030.490946] ueagle-atm 8-2:1.0: usbatm_usb_probe: trying driver ueagle-atm with vendor=1110, product=9031, ifnum 0
[ 3030.493691] uea_bind: setting usbatm
[ 3030.496932] usb 8-2: [ueagle-atm] using iso mode
[ 3030.497283] ueagle-atm 8-2:1.0: usbatm_usb_probe: using 3021 byte buffer for rx channel 0xffff880125953508
<kthread already started before usbatm_usb_probe() has returned>
[ 3030.497292] usb 8-2: [ueagle-atm] (re)booting started
<UPDATE_ATM_SIGNAL checks whether ATM device has been created yet before setting PHY state>
[ 3030.497298] uea_start_reset: atm dev (null)
<and since it hasn't been created yet PHY state is not set>
[ 3030.497306] ueagle-atm 8-2:1.0: usbatm_usb_probe: using 3392 byte buffer for tx channel 0xffff8801259535b8
[ 3030.497374] usbatm_usb_probe: about to init
[ 3030.497379] usbatm_usb_probe: calling usbatm_atm_init
<atm device finally gets created>
[ 3030.497384] usbatm_atm_init: creating atm device!
Signed-off-by: Dan Williams <dcbw@redhat.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Hans Verkuil