The Pinnacle Hybrid Pro 320e was missing a demod config for the xc3028, which
is required for digital tuning to work properly. Add the missing profile.
Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment.
Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In cases where the device has a generic Empia USB ID, the call in the
precard setup phase did not set the tuner GPIO. As a result, the tuner may
not be taken out of reset before attempting initialization in the analog
driver.
This problem was not seen before with the EVGA inDtube, since that particular
board has the analog GPIO setup to include taking the tuner out of reset.
Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment for the Pinnacle 320e.
Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Set the GPIO properly for the analog side of the Pinnacle Hybrid Pro, or else
the emp202 doesn't get detected properly.
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Setup the GPIOs properly and enable support for the DVB side of the Pinnacle
Hybrid Pro USB stick.
Thanks to Andreas Lunderhage for testing patches and providing a remote debug
environment.
Cc: Andreas Lunderhage <lunderhage@home.se>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Andy walls pointed out that we were passing 0x5d to the TUNER_GO register,
instead of 0x01. Set the register properly (note the code did still work with
the incorrect value, so this does not address a regression).
Thanks to Andy Walls for noticing the issue.
Cc: Andy Walls <awalls@radix.net>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
The Terratec Cinergy T XS USB can have either a zl10353 or an mt352. Add
support for the MT352 variant.
Thanks to Jelle de Jong for providing a unit to test/debug with.
Cc: Jelle de Jong <jelledejong@powercraft.nl>
Signed-off-by: Devin Heitmueller <dheitmueller@kernellabs.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Depending on the video input format, vinmode/vinctl needs adjustments.
For TV, this is not relevant, since the supported decoders output data
at the same format. However, webcam sensors may have different formats,
so, this needs to be adjusted based on the device.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
In order to properly estimate fps, mt9v011 sensor driver needs to know
what is the used frequency on the sensor cristal. Adds the proper fields
and initialization code for specifying the cristal frequency.
Also, based on experimentation, it was noticed that the Silvercrest is
outputing data at 7 fps. This means that it should be using a 6.3 MHz
cristal. This information needs to be double checked later, by opening
the device. Anyway, by using this value for xtal, at least now we have
the correct fps report.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Since frames per second is a function of cristal frequency, and this is
device-specific, add a function that allows adjusting it, via
subdev->core->s_config callback.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
It is possible to adjust the fps rate by changing some register values.
This is function of the connected Xtal at the camera sensor, being a 27
MHz cristal needed, in order to support 640x480 at 30 fps.
For now, it will only calculate the values for fps. Later patches may
introduce V4L2 ioctls, to allow frequency rate adjustments.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
While trying to fix an mt9v001 webcam, I noticed that HSCALE/VSCALE do
work with em28xx + webcam. The issue is that the scaling setup depends
on the number of visible rows/cols of the input image.
With mt9v011 (Silvercrest), the resolution is 640x480. So, the scaling
is different from a normal TV image (720x480 on NTSC). This were causing
a wrong scaling and a previous patch disabled scaling.
As each sensor have their different resolution setting, the xres/yres
should be adjusted accordingly with the input sensor.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
With the previous approach, autodetection were working only for the two
generic entries (em275x and em2820 unknown ones). So, if someone would
try to force probing an specific device, the code would not properly run
the autodetection code.
With the new approach, the sensor autodetection will be run not only for
the two generic entries, but also do webcam specific ones.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Instead of using em28xx board decoder field for storing sensor information,
let's use instead a separate field for it.
Also, as sensors are currently autodetected, there's no need of having
it at the boards description. So, move it to the main em28xx struct.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Webcams in general don't have eeprom. So, the sensor hint code should be
called to properly detect what sensor is inside.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
By having the webcam devices marked as such, it will help the em28xx
driver to do the right thing on those devices.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
Just renames the flag, to use a clearer name. Later patches will use
this flag to properly set some drivers behaviors for webcams.
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
A couple of erroneous register writes snuck in that made the image go haywire. Remove these.
Many thanks to Grégory Lardière for finding this out
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
All hdcs registers use bit 0 as a read/write flag and needs to be shifted one bit to the left. This wasn't accounted for when doing a sequence of writes.
Signed-off-by: Erik Andrén <erik.andren@gmail.com>
Signed-off-by: Mauro Carvalho Chehab <mchehab@redhat.com>
* 'tj-block-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc:
virtio_blk: mark virtio_blk with __refdata to kill spurious section mismatch
block: sysfs fix mismatched queue_var_{store,show} in 64bit kernel
ataflop: adjust NULL test
block: fix failfast merge testing in elv_rq_merge_ok()
z2ram: Small cleanup for z2ram.c
* git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-2.6: (37 commits)
sky2: Avoid races in sky2_down
drivers/net/mlx4: Adjust constant
drivers/net: Move a dereference below a NULL test
drivers/net: Move a dereference below a NULL test
connector: maintainer/mail update.
USB host CDC Phonet network interface driver
macsonic, jazzsonic: fix oops on module unload
macsonic: move probe function to .devinit.text
can: switch carrier on if device was stopped while in bus-off state
can: restart device even if dev_alloc_skb() fails
can: sja1000: remove duplicated includes
New device ID for sc92031 [1088:2031]
3c589_cs: re-initialize the multicast in the tc589_reset
Fix error return for setsockopt(SO_TIMESTAMPING)
netxen: fix thermal check and shutdown
netxen: fix deadlock on dev close
netxen: fix context deletion sequence
net: Micrel KS8851 SPI network driver
tcp: Use correct peer adr when copying MD5 keys
tcp: Fix MD5 signature checking on IPv4 mapped sockets
...
There's some odd bug in gcc-4.2 where it miscompiles a simple loop whent
he loop counter is of type 'unsigned char' and it should count to 128.
The compiler will incorrectly decide that a trivial loop like this:
unsigned char i, ...
for (i = 0; i < 128; i++) {
..
is endless, and will compile it to a single instruction that just
branches to itself.
This was triggered by the addition of '-fno-strict-overflow', and we
could play games with compiler versions and go back to '-fwrapv'
instead, but the trivial way to avoid it is to just make the loop
induction variable be an 'int' instead.
Thanks to Krzysztof Oledzki for reporting and testing and to Troy Moure
for digging through assembler differences and finding it.
Reported-and-tested-by: Krzysztof Oledzki <olel@ans.pl>
Found-by: Troy Moure <twmoure@szypr.net>
Gcc-bug-acked-by: Ian Lance Taylor <iant@google.com>
Cc: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Reset rx chain before trying to drain it.
Shut interrupts off last, incase there's something to report.
Signed-off-by: Mike McCormack <mikem@ring3k.org>
Acked-by: Stephen Hemminger <shemminger@vyatta.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Don't leak kernel stack information through uninitialized structure members.
Signed-off-by: Michael Buesch <mb@bu3sch.de>
Acked-by: Borislav Petkov <petkovbb@gmail.com>.
Signed-off-by: David S. Miller <davem@davemloft.net>
I'm using ide on 2.6.30.1 with xfs filesystem. I noticed a kernel memory
leak after writing lots of data, the kmalloc-96 slab cache keeps
growing. It seems the struct ide_cmd kmalloced by idedisk_prepare_flush
is never kfreed.
Commit a09485df9c ("ide: move request
type specific code from ide_end_drive_cmd() to callers (v3)") and
f505d49ffd ("ide: fix barriers support")
cause this regression, cmd->rq must now be set for ide_complete_cmd to
honor the IDE_TFLAG_DYN flag.
Signed-off-by: Maxime Bizon <mbizon@freebox.fr>
Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
The values in the advertising field are typically ADVERTISED_xxx, not
SUPPORTED_xxx. Both SUPPORTED_10000baseT_Full and
ADVERTISED_1000baseT_Full have the same value.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
struct ethtool_cmd E;
@@
*E.advertising = SUPPORTED_10000baseT_Full
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the NULL test is necessary, then the dereference should be moved below
the NULL test.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
type T;
expression E,E1;
identifier i,fld;
statement S;
@@
- T i = E->fld;
+ T i;
... when != E=E1
when != i
if (E == NULL||...) S
+ i = E->fld;
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
If the NULL test is necessary, then the dereferences should be moved below
the NULL test.
The semantic patch that makes this change is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
type T;
expression E,E1;
identifier i,fld;
statement S;
@@
- T i = E->fld;
+ T i;
... when != E=E1
when != i
BUG_ON (E == NULL||...);
+ i = E->fld;
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: David S. Miller <davem@davemloft.net>
Many Nokia handsets support a Phonet interface to the cellular modem
via a vendor-specific USB interface. CDC Phonet follows the
Communications Device Class model, with one control interface, and
and a pair of inactive and active data alternative interface. The later
has two bulk endpoint, one per direction.
This was tested against Nokia E61, Nokia N95, and the existing Phonet
gadget function for the Linux composite USB gadget framework.
Signed-off-by: Rémi Denis-Courmont <remi.denis-courmont@nokia.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Set the driver data before using it. Fixes an oops when doing rmmod.
Signed-off-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
A pointer to mac_sonic_probe is passed to the core via
platform_driver_register and so the function must not disappear when the
.init sections are discarded. Otherwise (if also having HOTPLUG=y)
unbinding and binding a device to the driver via sysfs will result in an
oops as does a device being registered late.
Various other functions that are called by mac_sonic_probe need to move
to .devinit.text, too.
An alternative to this patch is using platform_driver_probe instead of
platform_driver_register plus removing the pointer to the probe function
from the struct platform_driver.
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Tested-by: Finn Thain <fthain@telegraphics.com.au>
Signed-off-by: David S. Miller <davem@davemloft.net>
Netbooks based on the Soltech TA12 do not send a key release
for volume keys causing Linux to think the key is constantly
being pressed forever.
Added quirk data for forced release keys.
BugLink: https://bugs.launchpad.net//bugs/397499
Signed-off-by: Jerone Young <jerone.young@canonical.com>
Signed-off-by: Tim Gardner <tim.gardner@canonical.com>
Signed-off-by: Dmitry Torokhov <dtor@mail.ru>
Standard data flow for MMC/SD/SDIO cards requires that the mvsdio
controller be set for big endian operation. This is causing problems
with buffers which length is not a multiple of 4 bytes as the last
partial word doesn't get shifted all the way and stored properly in
memory. Let's compensate for this.
Signed-off-by: Nicolas Pitre <nico@marvell.com>
CC: stable@kernel.org
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This function does not have an error return and returning an error is
instead interpreted as having a lot of pending bytes.
Reported by Jeff Harris who provided a list of some of the remaining
offenders.
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
If spin_lock_irqsave is called twice in a row with the same second
argument, the interrupt state at the point of the second call overwrites
the value saved by the first call. Indeed, the second call does not
need to save the interrupt state, so it is changed to a simple
spin_lock.
The semantic match that finds this problem is as follows:
(http://www.emn.fr/x-info/coccinelle/)
// <smpl>
@@
expression lock1,lock2;
expression flags;
@@
*spin_lock_irqsave(lock1,flags)
... when != flags
*spin_lock_irqsave(lock2,flags)
// </smpl>
Signed-off-by: Julia Lawall <julia@diku.dk>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The buffer for the consoles are unconditionally allocated at con_init()
time, which miss the creation of the vcs(a) devices.
Since 2.6.30 (commit 4995f8ef9d, 'vcs:
hook sysfs devices into object lifetime instead of "binding"' to be
exact) these devices are no longer created at open() and removed on
close(), but controlled by the lifetime of the buffers.
Reported-by: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Tested-by: Gerardo Exequiel Pozzi <vmlinuz386@yahoo.com.ar>
Cc: stable@kernel.org
Signed-off-by: Kay Sievers <kay.sievers@vrfy.org>
Signed-off-by: Alan Cox <alan@linux.intel.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This patch fixes a problem when a device is stopped while in the
bus-off state. Then the carrier remains off forever.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@skynet.be>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
If dev_alloc_skb() failed in can_restart(), the device was left behind
in the bus-off state. This patch restarts the device nevertheless.
Signed-off-by: Kurt Van Dijck <kurt.van.dijck@eia.be>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
Remove duplicated #include('s) in
drivers/net/can/sja1000/sja1000.c
Signed-off-by: Huang Weiyi <weiyi.huang@gmail.com>
Signed-off-by: Wolfgang Grandegger <wg@grandegger.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
rain_maker@root-forum.org wrote:
> Hello cesar,
>
> In a recent thread in a german linux forum, a user reported his PIC
> NIC not being recognized by the kernel.
>
> Fortunately he provided enough information and I was able to help him
> and get the device working with the sc92031 driver.
>
> The device ID is [1088:2031] (Vendor is called "Microcomputer Systems
> (M) Son"), here is the respective thread in "ubuntuusers.de"
>
> http://forum.ubuntuusers.de/topic/lankarte-unter-xubuntu-wird-nicht-erkannt/
>
> (Although you might not speak german, the code provided will show
> you, that the device is actually working with your driver).
>
> It would be nice, if you include this new device ID to the
> sc92031-driver.
>
> Regards,
>
> Axel Köllhofer (aka Rain_Maker)
Cc: rain_maker@root-forum.org
Signed-off-by: Cesar Eduardo Barros <cesarb@cesarb.net>
Signed-off-by: David S. Miller <davem@davemloft.net>
3c589_cs:
re-initialize the multicast in the tc589_reset,
and spin_lock the set_multicast_list function.
Signed-off-by: Ken Kawasaki <ken_kawasaki@spring.nifty.jp>
Signed-off-by: David S. Miller <davem@davemloft.net>
