Bug 606806

Summary:	Backport V4L/DVB fixes from 2.6.32.25
Product:	Red Hat Enterprise Linux 6	Reporter:	Stanislaw Gruszka <sgruszka>
Component:	kernel	Assignee:	Stanislaw Gruszka <sgruszka>
Status:	CLOSED DUPLICATE	QA Contact:	desktop-bugs <desktop-bugs>
Severity:	medium	Docs Contact:
Priority:	low
Version:	6.0	CC:	cmeadors, jarod, mchehab, qcai
Target Milestone:	rc	Keywords:	OtherQA
Target Release:	---
Hardware:	All
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	663280 (view as bug list)		Environment:
Last Closed:	2011-01-12 09:11:51 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	663280, 682906

Description Stanislaw Gruszka 2010-06-22 14:22:35 UTC

Apply two upstream uvcvideo commits:

f4eabafeb3ea41801260fba624cbf2da971d19f8
"V4L/DVB (13148): uvcvideo: Handle V4L2_CTRL_TYPE_BUTTON control type in VIDIOC_QUERYCTRL"

and

cf7a50eeb6f462a0b7d1619fcb27a727a2981769
"V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0"

Comment 1 RHEL Program Management 2010-06-22 14:32:59 UTC

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux major release.  Product Management has requested further
review of this request by Red Hat Engineering, for potential inclusion in a Red
Hat Enterprise Linux Major release.  This request is not yet committed for
inclusion.

Comment 2 Stanislaw Gruszka 2010-06-25 08:33:20 UTC

I will post patches when "vcvideo: Prevent division by 0 when control step value is 0" will get -stable release.

Comment 3 RHEL Program Management 2010-07-15 13:59:18 UTC

This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.

** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **

Comment 4 Stanislaw Gruszka 2010-10-29 09:53:34 UTC

Second patch we wanted to backport (cf7a50eeb6f462a0b7d1619fcb27a727a2981769
"V4L/DVB: uvcvideo: Prevent division by 0 when control step value is 0") is fix for commit e54532e591cd5b9ce77dbc8d9786ae9f600f101a "V4L/DVB: uvcvideo: Clamp control values to the minimum and maximum values". This patch is not present in RHEL 6 hence we do not have to backport it (also both commits are not present in 2.6.32 -stable).

Comment 7 Jarod Wilson 2010-11-24 20:24:57 UTC

What if we were to, say, take a full backport of the entire current upstream staging/for_v2.6.38 v4l/dvb tree instead?...

Comment 8 Stanislaw Gruszka 2010-11-25 12:10:29 UTC

Hmm, is there anything that we really need? 

I considered adding 2.6.32.y -stable fixes to pretty safe, in opposite to backporting from new kernels, where can by lot of bugs in new code and new bugs introduced during backporting. And how we could test that backports? I don't think we have much video cameras and DVB adapters in house.

Comment 9 Jarod Wilson 2010-12-01 15:39:16 UTC

We definitely don't have every device out there, but I do at least have a fair sampling in my own possession, and am currently running a few systems at home with a test build carrying a full backport, routinely stressing a few of the more popular drivers (ivtv, cx18, em28xx, cx2388x, hdpvr)...

I'm thinking we'd need to seek testing assistance with some one-off builds from some of our larger customers who actually utilize this code.

Comment 10 Mauro Carvalho Chehab 2010-12-01 19:34:12 UTC

I have also some other devices, like cx23885, saa7134, several gspca-supported webcams, uvcvideo, etc.

It shouldn't hard to backport, as we have a backport tree that works since kernel 2.6.31.

Comment 11 Jarod Wilson 2010-12-01 19:42:13 UTC

(In reply to comment #10)
...
> It shouldn't hard to backport, as we have a backport tree that works since
> kernel 2.6.31.

Yeah, I've actually already done the leg work here -- which is mostly take the backport tree bits, overlay them on the rhel6 tree, then fix things up as necessary (kabi work-arounds). :)

(Reminds me... most of the initial issues I encountered with thinking something was rather broken in the backports tree were simply due to one of the backport patches no longer applying because of context changes. I have an updated patch that applies cleanly, but have yet to commit it.)

Comment 12 Jarod Wilson 2010-12-01 21:55:33 UTC

Everything builds fine out of tree from here again:

http://git.linuxtv.org/media_build.git

Then I've got a series of patches that can be overlaid on top of that to take care of kabi (well, actually... some of them probably need further cleaning/sanitization to do more than simply pass the kabi checks).

Comment 17 Stanislaw Gruszka 2010-12-15 09:34:25 UTC

I opened bug report for full backport. If it get acks we Jarod will do the backport, we close this one bug as duplicate. Otherwise I will post only -stable patches.

Comment 18 Stanislaw Gruszka 2011-01-12 09:11:51 UTC


*** This bug has been marked as a duplicate of bug 663280 ***