With mode DEVICE_MODE_RAW_TUNER a read occurs past the end of smscore_fw_lkup[].
Subsequently an attempt is made to load the firmware from the resulting
filename.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This patch changes most frontend drivers to allocate their state structure via
kzalloc and not kmalloc. This is done to properly initialize the
embedded "struct dvb_frontend frontend" field, that they all have.
The visible effect of this struct being uninitalized is, that the member "id"
that is used to set the name of kernel thread is totally random.
Some board drivers (for example cx88-dvb) set this "id" via
videobuf_dvb_alloc_frontend but most do not.
So I at least get random id values for saa7134, flexcop and ttpci based cards.
It looks like this in dmesg:
DVB: registering adapter 1 frontend -10551321 (ST STV0299 DVB-S)
The related kernel thread then also gets a strange name
like "kdvb-ad-1-fe--1".
Cc: Michael Krufky <mkrufky@linuxtv.org>
Cc: Steven Toth <stoth@linuxtv.org>
Cc: Timothy Lee <timothy.lee@siriushk.com>
Cc: Igor M. Liplianin <liplianin@me.by>
Signed-off-by: Matthias Schwarzott <zzam@gentoo.org>
Acked-by: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It tested the value of stk_sizes[i].m before checking whether i was in range.
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Cc: Trent Piepho <xyzzy@speakeasy.org>
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Restore support for digital tuning caused by regression during introduction
of disable_i2c_gate parameter to zl10353 driver.
Thanks to user "Xwang" for reporting the problem and testing the fix
Cc: Xwang <xwang1976@email.it>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The v4l core supplies default handlers for G_STD and G_PARM. However, both
default handlers are buggy.
This patch fixes the following:
1) If no g_std is supplied and current_norm == 0, then this driver does not
support TV video standards (e.g. a radio or webcam driver). Return
-EINVAL. This ensures that there is no bogus VIDIOC_G_STD support for
such drivers.
2) The default VIDIOC_G_PARM handler used current_norm instead of first
checking if the driver supported g_std and calling that to get the norm.
It also didn't check if current_norm was 0, since in that case the driver
does not support TV standards (or no standard was set at all) and the
default handler should return -EINVAL.
Note that I am very unhappy with these default handlers: I think they
basically behave like some very strange and unexpected side-effect.
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Drivers should either set current_norm or supply a g_std callback.
The hdpvr driver does neither. Since it initializes to a 60 Hz format
I've initialized the current_norm to NTSC | PAL_M | PAL_60 which is the
60 Hz subset of tvnorms.
Cc: Janne Grunau <j@jannau.net>
Signed-off-by: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The .buf_queue() V4L2 driver method is called under
spinlock_irqsave(q->irqlock,...), don't take the lock again inside the
function.
Reported-by: Antonio Ospite <ospite@studenti.unina.it>
Signed-off-by: Guennadi Liakhovetski <g.liakhovetski@gmx.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fix build errors in zr364xx by adding selects:
zr364xx.c:(.text+0x195ed7): undefined reference to `videobuf_streamon'
zr364xx.c:(.text+0x196030): undefined reference to `videobuf_dqbuf'
zr364xx.c:(.text+0x1960c4): undefined reference to `videobuf_qbuf'
zr364xx.c:(.text+0x196123): undefined reference to `videobuf_querybuf'
zr364xx.c:(.text+0x196182): undefined reference to `videobuf_reqbufs'
zr364xx.c:(.text+0x196224): undefined reference to `videobuf_queue_is_busy'
zr364xx.c:(.text+0x196390): undefined reference to `videobuf_vmalloc_free'
zr364xx.c:(.text+0x196571): undefined reference to `videobuf_iolock'
zr364xx.c:(.text+0x196678): undefined reference to `videobuf_mmap_mapper'
zr364xx.c:(.text+0x196760): undefined reference to `videobuf_poll_stream'
zr364xx.c:(.text+0x19689a): undefined reference to `videobuf_read_one'
zr364xx.c:(.text+0x1969ec): undefined reference to `videobuf_mmap_free'
zr364xx.c:(.text+0x197862): undefined reference to `videobuf_queue_vmalloc_init'
zr364xx.c:(.text+0x197a28): undefined reference to `videobuf_streamoff'
zr364xx.c:(.text+0x198203): undefined reference to `videobuf_to_vmalloc'
zr364xx.c:(.text+0x198603): undefined reference to `videobuf_streamoff'
drivers/built-in.o: In function `free_buffer':
zr364xx.c:(.text+0x19930c): undefined reference to `videobuf_vmalloc_free'
drivers/built-in.o: In function `zr364xx_open':
zr364xx.c:(.text+0x19a7de): undefined reference to `videobuf_queue_vmalloc_init'
drivers/built-in.o: In function `read_pipe_completion':
zr364xx.c:(.text+0x19b17f): undefined reference to `videobuf_to_vmalloc'
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: Douglas Schilling Landgraf <dougsland@redhat.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Register 0x13 seems to be a sort of image control, maybe gamma, white
level or black level. Lower values produce better images, while higher
values increases the contrast and shifts colors to green. 0xff produces
a black image. This register is not Silvercrest-specific, so its code
should be moved to a better place.
If this register is left alone, a random value can be found at the
register, producing weird results.
While here, let's remove register 0x0d, as it had no noticed effect at
the image.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Silvercrest mt9v011 sensor produces a 640x480 image. However,
previously, the code were getting only half of the lines and merging two
consecutive frames to "produce" a 640x480 image.
With the addition of progressive mode, now em28xx is working with a full
image. However, when the number of lines is bigger than 240, the
beginning of some odd lines are filled with blank.
After lots of testing, and physically checking the device for a Xtal, it
was noticed experimentally that mt9v011 is using em28xx XCLK as its
clock. Due to that, changing XCLK value changes the maximum speed of the
stream.
At the tests, it were possible to produce up to 32 fps, using a 30 MHz
XCLK. However, at that rate, the artifacts happen even at 320x240. Lower
values of XCLK produces artifacts only at 640x480.
At some values of xclk (for example XCLKK = 6 MHz, 640x480), it is
possible to see an invalid sucession of artifacts with this pattern:
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
.xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
...xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
....xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
(where the dots represent the blanked pixels)
So, it seems that a waveform in the format of a ramp is interferring at
the image.
The cause of this interference is currently unknown. Some possibilities
are:
- electrical interference (maybe this device is broken?);
- some issue at mt9v011 programming;
- some bug at em28xx chip.
So, for now, let's be conservative and use a value of XCLK that we know
for sure that it won't cause artifacts.
As I'm waiting for more of such devices with different em28xx chipset
revisions, I'll have the opportunity to double check the issue with
other pieces of hardware.
Later patches can vary XCLK depending on the vertical resolutions, if a
proper fix is not discovered.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx_pre_card_setup() is meant to contain board-specific initialization. Also,
as autodetection sometimes occur only after having i2c bus enabled, this
function may need to be called later.
Moving those setups to happen outside the function avoids calling it twice without
need and without duplicating output lines at dmesg.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
We don't know the xtal frequency of Silvercrest, but we need to have
some value in order to allow controlling the frame rate frequency. The
value is probably still wrong, since the manufacturer announces this
device as being capable of 30fps, but the maximum we can get is
13.5 fps.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Due to historical reasons, em28xx driver gets two consecutive frames and
fold them into an unique framing, doing interlacing. While this works
fine for TV images, this produces two bad effects with webcams:
1) webcam images are progressive. Merging two consecutive images produce
interlacing artifacts on the image;
2) since the driver needs to get two frames, it reduces the maximum
frame rate by two.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
As reported by hermann pitton <hermann-pitton@arcor.de>, some devices
has a different chip id for em2710 (likely the older ones):
em28xx: New device @ 480 Mbps (eb1a:2710, interface 0, class 0)
em28xx #0: Identified as EM2710/EM2750/EM2751 webcam grabber (card=22)
em28xx #0: em28xx chip ID = 17
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Thanks to hermann pitton <hermann-pitton@arcor.de> for pointing this new
variation.
Tested-by: hermann pitton <hermann-pitton@arcor.de>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
em28xx doesn't have temporal scaling. However, on webcams, sensors are
capable of changing the output rate. So, VIDIOC_[G|S]_PARM ioctls should
be passed to the sensor for it to properly set frame rate.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Implement g_parm/s_parm ioctls. Those are used to check the current
frame rate (in fps) and to set it to a value. In practice, there are
only 15 possible different speeds, due to chip limits.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A user discovered that the Geniatech x8000 encountered a regression when
the xc3028 power management was introduced. The xc3028 never recovers after
setting the powerdown register, which is probably because the xc3028 reset
GPIO is not properly configured. Since I do not have access to the hardware
and thus cannot determine the correct GPIO configuration, just disable xc3028
power management on this board, which fixes the regression.
Thanks to user "ritec" for reporting the issue and testing the fix.
Cc: rictec <rictec@netcabo.pt>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The introduction of the zl10353 i2c gate control broke support for the
Geniatech board (which is not behind an i2 gate). Add the needed parameter.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Remove the following build warning:
sms-cards.c: In function 'sms_board_event':
sms-cards.c:120: warning: unused variable 'board'
Thanks to Hans Verkuil for pointing this out.
The problem code has been #if 0'd for now, this will likely be
used again in the future, once the event interface is complete.
Cc: Hans Verkuil <hverkuil@xs4all.nl>
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The iSight sends non-UVC status events through the interrupt endpoint. Those
invalid events are reported to the kernel log, resulting in a log flood.
Only log the events when the UVC_TRACE_STATUS flag is set.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Commit 50144aeeb7 broke the Samsung NC10
netbook webcam. Instead of applying the FIX_BANDWIDTH quirk to all ViMicro
devices, list the devices explicitly.
Signed-off-by: Laurent Pinchart <laurent.pinchart@skynet.be>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The current GPIO configuration breaks all Hauppauge devices.
The code being removed affects Hauppauge devices only,
and is the cause of the breakage.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Currently, the VIDIOC_S_STD ioctl just returns -EINVAL regardless of
the norm passed. This patch sets cx23885_mpeg_template.tvnorms and
cx23885_mpeg_template.current_norm so that the VIDIOC_S_STD will work.
Thanks to Joseph Yasi for pointing this out, even though this particular
fix was already pushed into a development repository, merge priority of
this changeset has been escalated as a result of Joseph posting this
identical patch.
Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>
Signed-off-by: Joseph A. Yasi <joe.yasi@gmail.com>
Reviewed-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Current tip is broken and does not switch back to DVB-T correctly
Signed-off-by: Sohail Syyed <linuxtv@hubstar.net>
Signed-off-by: Steven Toth <stoth@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This device uses msp34xx and uses 2.048 MHz frequency for I2S
communication.
Thanks to Angelo Cano <acano@fastmail.fm> for pointing the issues with
this device and proposing an approach for fixing the issue.
Tested-by: Angelo Cano <acano@fastmail.fm>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Fixes stack corruption bug present in dump_regs function of zl10353 and
qt1010 drivers: the buffer buf was one byte smaller than required -
there are 4 chars for address prefix, 16 * 3 chars for dump of 16 eeprom
bytes per line and 1 byte for zero ending the string required, i.e. 53
bytes, but only 52 were provided.
The one byte missing in stack based buffer buf can cause stack
corruption possibly leading to kernel oops, as discovered originally
with af9015 driver (af9015: fix stack corruption bug).
Signed-off-by: Jan Nikitenko <jan.nikitenko@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Some mt9v011 webcams report 0x8332 chip version, instead of 0x8243. From
the revision history at the mt9v011 datasheet, it seems that the chip
version has changed from the first release of the chip.
Thanks-to hermann pitton <hermann-pitton@arcor.de> for pointing this to
me, on his tests with a Silvercrest webcam.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This mistakenly tested against sizeof(freqs) instead of the array size. Due to
the mask the only illegal value possible was 3.
Reported-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
This mistakenly tests against sizeof(freqs) instead of the array size. Due to
the mask the only illegal value possible was 3.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Andy Walls <awalls@radix.net>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
o Defer napi resouce allocation to device attach.
o Free napi resources and delete napi during detach.
This ensures right behavior across firmware reset.
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
o Remove private workqueue in the driver, move all
scheduled tasks to keventd workqueues. This makes
ports (interfaces) of same / different NIC boards
independent, in terms of their link watchdog and
reset tasks.
o Move quick checks for link status and temperature
in timer callback, schedule watchdog task only if
link status changed or temperature reached critical
threshold.
This also fixes deadlock when thermal panic occurs,
watchdog work was flushing workqueue that it was
sitting on.
Signed-off-by: Amit Kumar Salecha <amit@qlogic.com>
Signed-off-by: Dhananjay Phadke <dhananjay@netxen.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Currently setting rx-usecs when the interface is in legacy interrupt
mode it is not immediate. We were only setting EITR for each MSIx
vector and since this count would be zero for legacy mode it wasn't
set until after a reset. This patch corrects that by checking what
mode we are in and then setting EITR accordingly.
Signed-off-by: Don Skidmore <donald.skidmore@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For 'real' hardware CAN devices the netlink interface is used to set CAN
specific communication parameters. Real CAN hardware can not be created with
the ip tool ...
The invocation of 'ip link add type can' lead to an oops as the standard rtnl
newlink function was called:
http://bugzilla.kernel.org/show_bug.cgi?id=13954
This patch adds a private newlink function for the CAN device driver interface
that unconditionally returns -EOPNOTSUPP.
Signed-off-by: Oliver Hartkopp <oliver@hartkopp.net>
Reported-by: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com>
CC: Patrick McHardy <kaber@trash.net>
CC: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Fix another ocurring when the system resumes. This oops was due to driver
setting the pci drvdata to NULL on the prior hibernation. Becuase it was
set to NULL, upon resmume we assume the pci drvdata is non-zero, and we oops.
To fix the ooops, we don't set pci drvdata to NULL at hibernation time.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Fix oops ocurring at hibernation time. This oops was due to the firmware fault
watchdog timer still running after we freed resources. To fix the issue we need
to terminate the watchdog timer at hibernation time.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
This restriction is introduced just to avoid loop of
config_request. Retry must be limited so we have restricted
config request to maximum 2 times.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Inhibit 0x3117 loginfos - during cable pull, there are too many printks going
to the syslog, this is have impact on how fast the interrupt routine can handle
keeping up with command completions; this was the root cause to the config
pages timeouts.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
When a volume is activated, the driver will recieve a pair of ir config change
events to remove the foreign volume, then add the native.
In the process of the removal event, the hidden raid componet is removed from
the parent.When the disks is added back, the adding of the port fails becuase
there is no instance of the device in its parent.
To fix this issue, the driver needs to call mpt2sas_transport_update_links()
prior to calling _scsih_add_device. In addition, we added sanity checks on
volume add and removal to ignore events for foreign volumes.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Kernel panic is seen because driver did not tear down the port which should
be dnoe using mpt2sas_transport_port_remove(). without this fix When expander
is added back we would oops inside sas_port_add_phy.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
Kernel panic is seen because of enclosure_handle received from FW is zero.
Check is introduced before calling mpt2sas_config_get_enclosure_pg0.
Signed-off-by: Kashyap Desai <kashyap.desai@lsi.com>
Signed-off-by: James Bottomley <James.Bottomley@suse.de>
* 'for-linus' of git://neil.brown.name/md:
md: allow upper limit for resync/reshape to be set when array is read-only
md/raid5: Properly remove excess drives after shrinking a raid5/6
md/raid5: make sure a reshape restarts at the correct address.
md/raid5: allow new reshape modes to be restarted in the middle.
md: never advance 'events' counter by more than 1.
Remove deadlock potential in md_open
The driver always:
1. allocate cp->rx_buf_sz + NET_IP_ALIGN
2. map cp->rx_buf_sz
Signed-off-by: Francois Romieu <romieu@fr.zoreil.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Normally we only allow the upper limit for a reshape to be decreased
when the array not performing a sync/recovery/reshape, otherwise there
could be races. But if an array is part-way through a reshape when it
is assembled the reshape is started immediately leaving no window
to set an upper bound.
If the array is started read-only, the reshape will be suspended until
the array becomes writable, so that provides a window during which it
is perfectly safe to reduce the upper limit of a reshape.
So: allow the upper limit (sync_max) to be reduced even if the reshape
thread is running, as long as the array is still read-only.
Signed-off-by: NeilBrown <neilb@suse.de>
We were removing the drives, from the array, but not
removing symlinks from /sys/.... and not marking the device
as having been removed.
Signed-off-by: NeilBrown <neilb@suse.de>
This reverts commit 57921c312e.
On request from John Linville:
It has been shown to create a new problem. There is work
towards a solution to that one, but it isn't a simple
clean-up.
Signed-off-by: David S. Miller <davem@davemloft.net>
This "if" don't allow for the possibility that the number of devices
doesn't change, and so sector_nr isn't set correctly in that case.
So change '>' to '>='.
Signed-off-by: NeilBrown <neilb@suse.de>
md/raid5 doesn't allow a reshape to restart if it involves writing
over the same part of disk that it would be reading from.
This happens at the beginning of a reshape that increases the number
of devices, at the end of a reshape that decreases the number of
devices, and continuously for a reshape that does not change the
number of devices.
The current code is correct for the "increase number of devices"
case as the critical section at the start is handled by userspace
performing a backup.
It does not work for reducing the number of devices, or the
no-change case.
For 'reducing', we need to invert the test. For no-change we cannot
really be sure things will be safe, so simply require the array
to be read-only, which is how the user-space code which carefully
starts such arrays works.
Signed-off-by: NeilBrown <neilb@suse.de>
When assembling arrays, md allows two devices to have different event
counts as long as the difference is only '1'. This is to cope with
a system failure between updating the metadata on two difference
devices.
However there are currently times when we update the event count by
2. This was done to keep the event count even when the array is clean
and odd when it is dirty, which allows us to avoid writing common
update to spare devices and so allow those spares to go to sleep.
This is bad for the above reason. So change it to never increase by
two. This means that the alignment between 'odd/even' and
'clean/dirty' might take a little longer to attain, but that is only a
small cost. The spares will get a few more updates but that will
still be spared (;-) most updates and can still go to sleep.
Prior to this patch there was a small chance that after a crash an
array would fail to assemble due to the overly large event count
mismatch.
Signed-off-by: NeilBrown <neilb@suse.de>
Some gigabytes have on-board SIMG5723s connected to JMB ahcis. These
are used to implement hardware raid. Unfortunately some firmware
revisions on these 5723s don't bring the link down when all the
downstream ports are unoccupied while not responding to reset protocol
which makes libata think that there's device attached to the port but
is not responding and retry. This results in painfully wrong boot
detection time for these ports when they're empty.
This patch quirks those boards such that ahci gives up after the
initial timeout. Combined with parallel probing, this gives quick
enough probing and also is safe because SIMG5723 will respond to the
first try if any of the downstream ports is occupied.
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Marc Bowes <marcbowes@gmail.com>
Reported-by: Nicolas Mailhot <Nicolas.Mailhot@LaPoste.net>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Too strong words led to spurious bug reports: Novell bugzilla #527748,
RedHat bugzilla #468800. This patch is used to soften up the dmesg on
SB600 PMP softreset failure recovery, so as to remove the scariness and
concern from community.
Reported-by: pgnet Dev <pgnet.dev@gmail.com>
Signed-off-by: Shane Huang <shane.huang@amd.com>
Cc: Tejun Heo <tj@kernel.org>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
At least the nVidia MCP55 controller quite happily supports MSI.
This adds an option to use it. It is disabled by default.
As per feedback by Robert Hancock, it will honour the user
request as the kernel will not enable MSI where the controller
or the specific system configuration do not support it.
Signed-off-by: Tony Vroon <tony@linx.net>
Cc: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
OCZ Vertex SSD can't do HPA and not in a usual way. It reports HPA,
allows unlocking but then fails all IOs which fall in the unlocked
area. Quirk it so that HPA unlocking is not used for the device.
Reported by Daniel Perup in bnc#522414.
https://bugzilla.novell.com/show_bug.cgi?id=522414
Signed-off-by: Tejun Heo <tj@kernel.org>
Reported-by: Daniel Perup <probe@spray.se>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
PIO and MWDMA timings are never programmed for the second channel
because timing registers are treated as 16-bit long ones.
The bug is an attixp -> pata_atiixp regression and goes back to:
commit 669a5db411
Author: Jeff Garzik <jeff@garzik.org>
Date: Tue Aug 29 18:12:40 2006 -0400
[libata] Add a bunch of PATA drivers.
Cc: Krystian Juskowiak <jusko@tlen.pl>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: Borislav Petkov <bbpetkov@yahoo.de>
Cc: Robert Hancock <hancockrwd@gmail.com>
Signed-off-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Julias Lawall discovered that pata_at91 wasn't freeing a memory region
allocated with kzalloc() on init failure paths. Upon review,
pata_at91 also seems to be doing unnecessary explicit resource
releases for managed resources too. Convert memory allocation to
managed one and drop unnecessary explicit resource releases.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Julia Lawall <julia@diku.dk>
Cc: Sergey Matyukevich <geomatsi@gmail.com>
Signed-off-by: Jeff Garzik <jgarzik@redhat.com>
Commit 783ea7d4ee
(Driver Core: Rework platform suspend/resume, print warning)
added a warning message printed for platform drivers that use the
legacy PM callbacks rather than struct dev_pm_ops. Unfortunately,
this resulted in some confusion and made some people try to convert
drivers by replacing the old callbacks with struct dev_pm_ops in
automatic way, which generally is not a good idea.
Remove the platform device runtime dev_pm_ops warning for now,
because it's annoying to users and it's not really necessary right
now.
[rjw: Modified the changelog to be more informative.]
Signed-off-by: Magnus Damm <damm@igel.co.jp>
Acked-by: Greg Kroah-Hartman <gregkh@suse.de>
Signed-off-by: Rafael J. Wysocki <rjw@sisk.pl>
queue == __AR9170_NUM_TXQ would cause a bug on the next line.
found by Smatch ( http://repo.or.cz/w/smatch.git ).
Cc: stable@kernel.org
Reported-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Dan Carpenter <error27@gmail.com>
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
When ar9170-2.fw was missing, the driver erroneously complained
about missing the initialization values file ar9170-1.fw...
Signed-off-by: Christian Lamparter <chunkeey@web.de>
Signed-off-by: John W. Linville <linville@tuxdriver.com>
Commit d945cb9cc ("pty: Rework the pty layer to use the normal buffering
logic") dropped the test for 'tty->stopped' in pty_write_room(), which
then causes the n_tty line discipline thing to not throttle the data
properly when the tty is stopped.
So instead of pausing the write due to the tty being stopped, the ldisc
layer would go ahead and push it down to the pty. The pty write()
routine would then refuse to take the data (because it _did_ check
'stopped'), and the data wouldn't actually be written.
This whole stopped test should eventually be moved into the tty ldisc
layer rather than have low-level tty drivers care about these things,
but right now the fix is to just re-instate the missing pty 'stopped'
handling.
Reported-and-tested-by: Artur Skawina <art.08.09@gmail.com>
Cc: Alan Cox <alan@lxorguk.ukuu.org.uk>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6:
PCI hotplug: SGI hotplug: do not use hotplug_slot_attr
PCI hotplug: SGI hotplug: fix build failure
If the length is less or equal to frag_prefix_size in the first iteration
we write skb_frags_rx[-1] and read from priv->frag_info[-1]
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Prevent read from cards[-1] when no card was found.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
An `options[cards_found]' that equals `sizeof(options_mapping)' is already beyond
the array.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If vlan has been enabled. ifdown followed by ifup will lost hardware
related state.
Also remove duplicated operation in gfar_vlan_rx_register().
Signed-off-by: Yong Zhang <yong.zhang0@gmail.com>
Acked-by: Dai Haruki <dai.haruki@freescale.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The bank offset was being incorrectly calculated on ICH9 parts with a bank
size of 8K (instead of the more common 4K bank) which would cause any NVM
writes to be done on the wrong address after switching from bank 1 to bank
0. Additionally, assume we are meant to use bank 0 if a valid bank is not
detected, and remove the unnecessary acquisition of the SW/FW/HW semaphore
when writing to the shadow ram version of the NVM image.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For ICHx parts, write the EXTCNF_CTRL.SWFLAG bit once when trying to
acquire the SW/FW/HW semaphore instead of multiple times to prevent the
hardware from having problems (especially for systems with manageability
enabled), and extend the timeout for the hardware to set the SWFLAG bit.
Signed-off-by: Bruce Allan <bruce.w.allan@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
For 82599, packet split has to be disabled for FCoE direct data placement.
However, this is only required on received queues allocated for FCoE. This
patch adds a per ring flags to indicate if packet split is disabled on a
per queue basis, particularly for FCoE, as packet split must be disabled
for large receive using direct data placement (DDP).
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Instead of passing the register index of the corresponding rx_ring and find
the way back to get to corresponding rx_ring in ixgbe_configure_srrctl(),
simplify the function ixgbe_configure_srrctl() by passing the rx_ring into
it. Then the register index for that rx_ring is already available from
rx_ring->reg_idx.
Signed-off-by: Yi Zou <yi.zou@intel.com>
Acked-by: Peter P Waskiewicz Jr <peter.p.waskiewicz.jr@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
As it is, parts of the ioctl runs under the RTNL and parts of
it do not. The unlocked section is still protected by the BKL,
but there can be subtle races. For example, Eric Biederman and
Paul Moore observed that if two threads tried to create two tun
devices on the same file descriptor, then unexpected results
may occur.
As there isn't anything in the ioctl that is expected to sleep
indefinitely, we can prevent this from occurring by extending
the RTNL lock coverage.
This also allows to get rid of the BKL.
Finally, I changed tun_get_iff to take a tun device in order to
avoid calling tun_put which would dead-lock as it also tries to
take the RTNL lock.
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Commit f0b3fbeae1 ("FEC Buffer rework")
breaks transmission of packets where the skb data buffer is not memory
aligned according to FEC_ALIGNMENT. It incorrectly passes to
dma_sync_single() the buffer address directly from the skb, instead of
the address calculated for use (which may be the skb address or one of
the bounce buffers).
It seems there is no use converting the cpu address of the buffer to
a physical either, since dma_map_single() expects the cpu address and
will return the dma address to use in the descriptor. So remove the use
of __pa() on the buffer address as well.
This patch is against 2.6.30-rc5. This breakage is a regression over
2.6.30, which does not have this problem.
Signed-off-by: Greg Ungerer <gerg@uclinux.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
strlcpy() will always null terminate the string.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Jay Cliburn <jcliburn@gmail.com>
Cc: Chris Snook <csnook@redhat.com>
Cc: Jie Yang <jie.yang@atheros.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
io[i] is read before the bounds check on i, order should be reversed.
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Cc: Samuel Ortiz <samuel@sortiz.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
A recent commit:
commit 449aad3e25
introduced the possibility of an A-B/B-A deadlock between
bd_mutex and reconfig_mutex.
__blkdev_get holds bd_mutex while calling md_open which takes
reconfig_mutex,
do_md_run is always called with reconfig_mutex held, and it now
takes bd_mutex in the call the revalidate_disk.
This potential deadlock was not caught by lockdep due to the
use of mutex_lock_interruptible_nexted which was introduced
by
commit d63a5a74de
do avoid a warning of an impossible deadlock.
It is quite possible to split reconfig_mutex in to two locks.
One protects the array data structures while it is being
reconfigured, the other ensures that an array is never even partially
open while it is being deactivated.
In particular, the second lock prevents an open from completing
between the time when do_md_stop checks if there are any active opens,
and the time when the array is either set read-only, or when ->pers is
set to NULL. So we can be certain that no IO is in flight as the
array is being destroyed.
So create a new lock, open_mutex, just to ensure exclusion between
'open' and 'stop'.
This avoids the deadlock and also avoids the lockdep warning mentioned
in commit d63a5a74d
Reported-by: "Mike Snitzer" <snitzer@gmail.com>
Reported-by: "H. Peter Anvin" <hpa@zytor.com>
Signed-off-by: NeilBrown <neilb@suse.de>
Some applications/hardware combinations are triggering the message "failed to
acquire vblank counter" to be issued up to 20 times a second, which makes it
both useless and dangerous, as this may hide other important messages.
This changes makes it only appear when people are debugging.
Signed-off-by: Paul Rolland <rol@as2917.net>
Reviewed-by: Jesse Barnes <jbarnes@virtuousgeek.org>
Lost-twice-by: Dave Airlie <airlied@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
The code which takes probed modes and adds them to a connector eliminates
duplicate modes by comparing them using drm_mode_equal. That function
doesn't consider the type bits, which means that any modes which differ only
in the type field will be lost.
One of the bits in the mode->type field is the DRM_MODE_TYPE_PREFERRED bit.
If the mode with that bit is lost, then higher level code will not know
which mode to select, causing a random mode to be used instead.
This patch simply merges the two mode type bits together; that seems
reasonable to me, but perhaps only a subset of the bits should be used? None
of these can be user defined as they all come from looking at just the
hardware.
Signed-off-by: Keith Packard <keithp@keithp.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb-2.6:
USB: fix oops on disconnect in cdc-acm
USB: storage: include Prolific Technology USB drive in unusual_devs list
USB: ftdi_sio: add product_id for Marvell OpenRD Base, Client
USB: ftdi_sio: add vendor and product id for Bayer glucose meter serial converter cable
USB: EHCI: fix counting of transaction error retries
USB: EHCI: fix two new bugs related to Clear-TT-Buffer
USB: usbfs: fix -ENOENT error code to be -ENODEV
USB: musb: fix the nop registration for OMAP3EVM
USB: devio: Properly do access_ok() checks
USB: pl2303: New vendor and product id
* git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging-2.6:
Staging: rspiusb: Fix buffer overflow
staging: add dependencies on PCI for drivers that require it
Staging: rtl8192su: fix build error
Staging: rt2870: Revert d44ca7 Removal of kernel_thread() API
Staging: rt2870: Add USB ID for Linksys, Planex Communications, Belkin
* 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/anholt/drm-intel: (22 commits)
drm/i915: Fix read outside array bounds in restoring the SWF10 range.
drm/i915: Use our own workqueue to avoid wedging the system along with the GPU.
drm/i915: Add support for dual-channel LVDS on 8xx.
drm/i915: Return disconnected for SDVO DVI when there's no digital EDID.
drm/i915: Choose real sdvo output according to result from detection
drm/i915: Set preferred mode for integrated TV according to TV format
drm/i915: fix 845G FIFO size & burst length
drm/i915: fix VGA detect on IGDNG
drm/i915: Add eDP support on IGDNG mobile chip
drm/i915: enable DisplayPort support on IGDNG
drm/i915: Fix channel ending action for DP aux transaction
drm/i915: fix issue in display pipe setup on IGDNG
drm/i915: disable VGA plane reliably
drm/I915: Fix offset to DVO timings in LVDS data
drm/i915: hdmi detection according by reading edid
drm/i915: correct self-refresh calculation in "everything off" case
drm/i915: handle FIFO oversubsription correctly
drm/i915: FIFO watermark calculation fixes
drm/i915: ignore lvds on AOpen Mini PC MP-915
drm/i915: Allow frame buffers up to 4096x4096 on 915/945 class hardware
...
usb_buffer_map_sg() may return -1. This will result in a read from
pdx->PixelUrb[frameInfo][-1]
Signed-off-by: Roel Kluin <roel.kluin@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch adds PCI dependencies to staging drivers that require it.
Signed-off-by: Jeff Mahoney <jeffm@suse.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This fixes a build error when selecting the rtl8192su driver as a
module. This has been reported by me, and the opensuse kernel developer
team, and I finally tracked it down.
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Staging: rt2870: Revert d44ca7 Removal of kernel_thread() API
The sanity check this patch introduced triggers on shutdown, apparently due to
threads having already exited by the time BUG_ON() is reached.
Signed-off-by: Mike Galbraith <efault@gmx.de>
Cc: Peter Teoh <htmldeveloper@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
This patch fixes an oops caused when during an unplug a device's table
of endpoints is zeroed before the driver is notified. A pointer to
the endpoint must be cached.
this fixes a regression caused by commit
5186ffee23
Therefore it should go into 2.6.31
Signed-off-by: Oliver Neukum <oliver@neukum.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Add a quirk entry for the Leading Driver UD-11 usb flash drive.
As Alan Stern told me, the device doesn't deal correctly with the
locking media feature of the device, and this patch incorporates it.
Compiled, tested, working.
Signed-off-by: Rogerio Brito <rbrito@ime.usp.br>
Cc: Phil Dibowitz <phil@ipom.com>
Cc: Alan Stern <stern@rowland.harvard.edu>
Cc: Robert Hancock <hancockrwd@gmail.com>
Cc: stable <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
Roel Kluin