linux-toradex.git/drivers, branch v2.6.27.43

S390: dasd: support DIAG access for read-only devices

2010-01-06T23:17:15+00:00

commit 22825ab7693fd29769518a0d25ba43c01a50092a upstream.

When a DASD device is used with the DIAG discipline, the DIAG
initialization will indicate success or error with a respective
return code. So far we have interpreted a return code of 4 as error,
but it actually means that the initialization was successful, but
the device is read-only. To allow read-only devices to be used with
DIAG we need to accept a return code of 4 as success.

Re-initialization of the DIAG access is also part of the DIAG error
recovery. If we find that the access mode of a device has been
changed from writable to read-only while the device was in use,
we print an error message.

Signed-off-by: Stefan Weinhuber 
Signed-off-by: Martin Schwidefsky 
Cc: Stephen Powell 
Signed-off-by: Greg Kroah-Hartman

i2c/tsl2550: Fix lux value in extended mode

2010-01-06T23:17:12+00:00

commit 5f5bfb09d81c9a1d26238ae6668e584c14ae3daf upstream.

According to the TAOS Application Note 'Controlling a Backlight with
the TSL2550 Ambient Light Sensor' (page 14), the actual lux value in
extended mode should be obtained multiplying the calculated lux value
by 5.

Signed-off-by: Michele Jr De Candia 
Signed-off-by: Jean Delvare 
Signed-off-by: Greg Kroah-Hartman

pata_cmd64x: fix overclocking of UDMA0-2 modes

2010-01-06T23:17:09+00:00

commit 509426bd46ad0903dca409803e0ee3d30f99f1e8 upstream.

adev->dma_mode stores the transfer mode value not UDMA mode number
so the condition in cmd64x_set_dmamode() is always true and the higher
UDMA clock is always selected.  This can potentially result in data
corruption when UDMA33 device is used, when 40-wire cable is used or
when the error recovery code decides to lower the device speed down.

The issue was introduced in the commit 6a40da0 ("libata cmd64x: whack
into a shape that looks like the documentation") which goes back to
kernel 2.6.20.

Signed-off-by: Bartlomiej Zolnierkiewicz 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman

Libertas: fix buffer overflow in lbs_get_essid()

2010-01-06T23:17:07+00:00

commit 45b241689179a6065384260242637cf21dabfb2d upstream.

The libertas driver copies the SSID buffer back to the wireless core and
appends a trailing NULL character for termination. This is

a) unnecessary because the buffer is allocated with kzalloc and is hence
   already NULLed when this function is called, and

b) for priv->curbssparams.ssid_len == 32, it writes back one byte too
   much which causes memory corruptions.

Fix this by removing the extra write.

Signed-off-by: Daniel Mack 
Cc: Stephen Hemminger 
Cc: Maithili Hinge 
Cc: Kiran Divekar 
Cc: Michael Hirsch 
Cc: netdev@vger.kernel.org
Cc: libertas-dev@lists.infradead.org
Cc: linux-wireless@lists.infradead.org
Acked-by: Holger Schurig 
Acked-by: Dan Williams 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

matroxfb: fix problems with display stability

2009-12-18T21:31:04+00:00

commit 8c651311a3a08c1e4815de6933e00a760e498dae upstream.

Regression caused in 2.6.23 and then despite repeated requests never fixed
or dealt with (Petr promised to sort it in 2008 but seems to have
forgotten).

Enough is enough - remove the problem line that was added.  If it upsets
someone they've had two years to deal with it and at the very least it'll
rattle their cage and wake them up.

Addresses http://bugzilla.kernel.org/show_bug.cgi?id=9709

Signed-off-by: Alan Cox 
Reported-by: Damon 
Tested-by: Ruud van Melick 
Cc: Petr Vandrovec 
Cc: Pekka Enberg 
Cc: Paul A. Clarke 
Signed-off-by: Andrew Morton 
Signed-off-by: Linus Torvalds 
Signed-off-by: Greg Kroah-Hartman

backlight: lcd - Fix wrong sizeof

2009-12-18T21:31:01+00:00

commit 1e0fa6bd8c7468067f2e988c7a416dafd0651c34 upstream.

Which is why I have always preferred sizeof(struct foo) over
sizeof(var).

Signed-off-by: Jean Delvare 
Signed-off-by: Richard Purdie 
Signed-off-by: Greg Kroah-Hartman

USB: fix mos7840 problem with minor numbers

2009-12-18T21:30:59+00:00

commit 37768adf9a1d49aeac0db1ba3dc28b3274b7b789 upstream

This patch fixes a problem with any mos7840 device where the use of the
field "minor" before it is initialised results in all the devices being
overlaid in memory (minor = 0 for all instances)

Contributed by: Phillip Branch

Backported to .27 by Christoph Biedl 

Signed-off-by: Tony Cook 
Signed-off-by: Greg Kroah-Hartman

V4L/DVB: Fix test in copy_reg_bits()

2009-12-18T21:30:49+00:00

commit c95a419a5604ec8a23cd73f61e9bb151e8cbe89b upstream.

The reg_pair2[j].reg was tested twice.

Signed-off-by: Roel Kluin 
Acked-by: Michael Krufky 
Signed-off-by: Andrew Morton 
Signed-off-by: Mauro Carvalho Chehab 
Signed-off-by: Greg Kroah-Hartman

ssb: Fix range check in sprom write

2009-12-18T21:30:47+00:00

commit e33761e6f23881de9f3ee77cc2204ab2e26f3d9a upstream.

The range check in the sprom image parser hex2sprom() is broken.
One sprom word is 4 hex characters.
This fixes the check and also adds much better sanity checks to the code.
We better make sure the image is OK by doing some sanity checks to avoid
bricking the device by accident.

Signed-off-by: Michael Buesch 
Signed-off-by: John W. Linville 
Signed-off-by: Greg Kroah-Hartman

pata_hpt{37x|3x2n}: fix timing register masks (take 2)

2009-12-18T21:30:46+00:00

commit 5600c70e576199a7552e1c0fff43f3fe16f5566e upstream.

These drivers inherited from the older 'hpt366' IDE driver the buggy timing
register masks in their set_piomode() metods. As a result, too low command
cycle active time is programmed for slow PIO modes.  Quite fortunately, it's
later "fixed up" by the set_dmamode() methods which also "helpfully" reprogram
the command timings, usually to PIO mode 4; unfortunately, setting an UltraDMA
mode #N also reprograms already set PIO data timings, usually to MWDMA mode #
max(N, 2) timings...

However, the drivers added some breakage of their own too:  the bit that they
set/clear to control the FIFO is sometimes wrong -- it's actually the MSB of
the command cycle setup time; also, setting it in DMA mode is wrong as this
bit is only for PIO actually and clearing it for PIO modes is not needed as
no mode in any timing table has it set...

Fix all this, inverting the masks while at it, like in the 'hpt366' and
'pata_hpt366' drivers; bump the drivers' versions, accounting for recent
patches that forgot to do it...

Signed-off-by: Sergei Shtylyov 
Signed-off-by: Jeff Garzik 
Signed-off-by: Greg Kroah-Hartman