Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 17 2月, 2009 5 次提交
    • A
      V4L/DVB (10619): gspca - main: Destroy the URBs at disconnection time. · ad28127d
      由 Adam Baker 提交于 
      If a device using the gspca framework is unplugged while it is still streaming
then the call that is used to free the URBs that have been allocated occurs
after the pointer it uses becomes invalid at the end of gspca_disconnect.
Make another cleanup call in gspca_disconnect while the pointer is still
valid (multiple calls are OK as destroy_urbs checks for pointers already
being NULL.
Signed-off-by: NAdam Baker <linux@baker-net.org.uk>
Signed-off-by: NJean-Francois Moine <moinejf@free.fr>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ad28127d
    • M
      V4L/DVB (10572): Revert commit dda06a8e · 28100165
      由 Mauro Carvalho Chehab 提交于 
      On Mon, 02 Feb 2009, Hartmut wrote:

This change set is wrong. The affected functions cannot be called from
an interrupt context, because they may process large buffers. In this
case, interrupts are disabled for a long time. Functions, like
dvb_dmx_swfilter_packets(), could be called only from a tasklet.

This change set does hide some strong design bugs in dm1105.c and
au0828-dvb.c.

Please revert this change set and do fix the bugs in dm1105.c and
au0828-dvb.c (and other files).

On Sun, 15 Feb 2009, Oliver Endriss wrote:

This changeset _must_ be reverted! It breaks all kernels since 2.6.27
for applications which use DVB and require a low interrupt latency.

It is a very bad idea to call the demuxer to process data buffers with
interrupts disabled!

On Mon, 16 Feb 2009, Trent Piepho wrote:

I agree, this is bad.  The demuxer is far too much work to be done with
IRQs off.  IMHO, even doing it under a spin-lock is excessive.  It should
be a mutex.  Drivers should use a work-queue to feed the demuxer.

Thank you for testing this changeset and discovering the issues on it.

Cc: Trent Piepho <xyzzy@speakeasy.org>
Cc: Hartmut <e9hack@googlemail.com>
Cc: Oliver Endriss <o.endriss@gmx.de>
Cc: Andreas Oberritter <obi@linuxtv.org>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      28100165
    • T
      V4L/DVB (10533): fix LED status output · 2f94fc46
      由 Tobias Lorenz 提交于 
      This patch closes one of my todos that was since long on my list.
Some people reported clicks and glitches in the audio stream,
correlated to the LED color changing cycle.
Thanks to Rick Bronson <rick@efn.org>.
Signed-off-by: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      2f94fc46
    • T
      V4L/DVB (10532): Correction of Stereo detection/setting and signal strength indication · d807dec5
      由 Tobias Lorenz 提交于 
      Thanks to Bob Ross <pigiron@gmx.com>
- correction of stereo detection/setting
- correction of signal strength indicator scaling
Signed-off-by: NTobias Lorenz <tobias.lorenz@gmx.net>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      d807dec5
    • M
      V4L/DVB (10527): tuner: fix TUV1236D analog/digital setup · ef88f2b5
      由 Mauro Carvalho Chehab 提交于 
      As reported by David Engel <david@istwok.net>, ATSC115 doesn't work
fine with mythtv. This software opens both analog and dvb interfaces of
saa7134.

What happens is that some tuner commands are going to the wrong place,
as shown at the logs:

Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner 1-0061: tv freq set to 67.25
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: using tuner params #0 (ntsc)
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: freq = 67.25 (1076), range = 0, config = 0xce, cb = 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: Freq= 67.25 MHz, V_IF=45.75 MHz, Offset=0.00 MHz, div=1808
Feb 12 20:37:48 opus kernel: tuner-simple 1-000a: tv 0x07 0x10 0xce 0x01
Feb 12 20:37:48 opus kernel: tuner-simple 1-0061: tv 0x07 0x10 0xce 0x01

This happens due to a hack at TUV1236D analog setup, where it replaces
tuner address, at 0x61 for 0x0a, in order to save a few memory bytes.

The code assumes that nobody else would try to access the tuner during
that setup, but the point is that there's no lock to protect such
access. So, this opens the possibility of race conditions to happen.

Instead of hacking tuner address, this patch uses a temporary var with
the proper tuner value to be used during the setup. This should save
the issue, although we should consider to write some analog/digital
lock at saa7134 driver.
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      ef88f2b5
  3. 13 2月, 2009 17 次提交
  5. 12 2月, 2009 14 次提交
  7. 11 2月, 2009 4 次提交
    • S
      [S390] dasd: fix race in dasd timer handling · 48cae885
      由 Stefan Weinhuber 提交于 
      In dasd_device_set_timer and dasd_block_set_timer we interpret the
return value of mod_timer in a wrong way. If the timer expires in
the small window between our check of timer_pending and the call to
mod_timer, then the timer will be set, mod_timer returns zero and
we will call add_timer for a timer that is already pending.
As del_timer and mod_timer do all the necessary checking themselves,
we can simplify our code and remove the race a the same time.
Signed-off-by: NStefan Weinhuber <wein@de.ibm.com>
Signed-off-by: NMartin Schwidefsky <schwidefsky@de.ibm.com>
      48cae885
    • C
      [S390] dasd: bus_id -> dev_name() conversion. · ca0b4b7d
      由 Cornelia Huck 提交于 
      bus_id usage crept in again; fix it.
Signed-off-by: NCornelia Huck <cornelia.huck@de.ibm.com>
Signed-off-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      ca0b4b7d
    • M
      sunhme: Fix Quattro HME irq registration on proble failures · 7b7a799d
      由 Meelis Roos 提交于 
      Currently, the sunhme driver installs SBus Quattro interrupt handler 
when at least one HME card was initialized correctly and at least one 
Quattro card is present. This breaks when a Quattro card fails 
initialization for whatever reason - IRQ is registered and OOPS happens 
when it fires.

The solution, as suggested by David Miller, was to keep track which 
cards of the Quattro bundles have been initialized, and request/free the 
Quattro IRQ only when all four devices have been successfully 
initialized.

The patch only touches SBus initialization - PCI init already resets the 
card pointer to NULL on init failure.

The patch has been tested on Sun E3500 with SBus and PCI single HME 
cards and one PCI Quattro HME card in a situation where any PCI card 
failed init when the SBus routines tried to init them by mistake.

Additionally it replaces Quattro request_irq panic with error return - 
if this card fails to work, at least let the others work.

Tested on E450 with PCI HME and PCI Quad HME.

[ Minor coding style fixups -DaveM ]
Signed-off-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      7b7a799d
    • M
      fore200: fix oops on failed firmware load · fcffd0d8
      由 Meelis Roos 提交于 
      Fore 200 ATM driver fails to handle request_firmware failures and oopses 
when no firmware file was found. Fix it by checking for the right return 
values and propaganting the return value up.
Signed-off-by: NMeelis Roos <mroos@linux.ee>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      fcffd0d8