[PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[Michael Krufky]

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Could somebody please test this patch and confirm that it doesn't
break the af9005 support?

This patch removes the af9005_usb_generic_rw function and uses the
dvb_usb_generic_rw function instead, using
generic_bulk_ctrl_endpoint_response to differentiate between the read
pipe and the write pipe.

Also found in the mercurial repository:

http://kernellabs.com/hg/~mkrufky/af9005

Cheers,

Mike Krufky

[-- Attachment #2: 8d43c09cfe26.patch --]
[-- Type: application/octet-stream, Size: 2958 bytes --]


# HG changeset patch
# User Michael Krufky <mkrufky@kernellabs.com>
# Date 1277095782 14400
# Node ID 8d43c09cfe26655166e7ab039f765223bc87f3c5
# Parent 723e03a57ef335a4e005ac57e49fa50d2c66a010
af9005: use generic_bulk_ctrl_endpoint_response

From: Michael Krufky <mkrufky@kernellabs.com>

Priority: normal

Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>

--- a/linux/drivers/media/dvb/dvb-usb/af9005.c	Sun Jan 31 19:06:10 2010 -0500
+++ b/linux/drivers/media/dvb/dvb-usb/af9005.c	Mon Jun 21 00:49:42 2010 -0400
@@ -54,50 +54,6 @@
 	int led_state;
 };
 
-static int af9005_usb_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen,
-			  u8 *rbuf, u16 rlen, int delay_ms)
-{
-	int actlen, ret = -ENOMEM;
-
-	if (wbuf == NULL || wlen == 0)
-		return -EINVAL;
-
-	if ((ret = mutex_lock_interruptible(&d->usb_mutex)))
-		return ret;
-
-	deb_xfer(">>> ");
-	debug_dump(wbuf, wlen, deb_xfer);
-
-	ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev,
-						    2), wbuf, wlen,
-			   &actlen, 2000);
-
-	if (ret)
-		err("bulk message failed: %d (%d/%d)", ret, wlen, actlen);
-	else
-		ret = actlen != wlen ? -1 : 0;
-
-	/* an answer is expected, and no error before */
-	if (!ret && rbuf && rlen) {
-		if (delay_ms)
-			msleep(delay_ms);
-
-		ret = usb_bulk_msg(d->udev, usb_rcvbulkpipe(d->udev,
-							    0x01), rbuf,
-				   rlen, &actlen, 2000);
-
-		if (ret)
-			err("recv bulk message failed: %d", ret);
-		else {
-			deb_xfer("<<< ");
-			debug_dump(rbuf, actlen, deb_xfer);
-		}
-	}
-
-	mutex_unlock(&d->usb_mutex);
-	return ret;
-}
-
 static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
 			      int readwrite, int type, u8 * values, int len)
 {
@@ -146,7 +102,7 @@
 		obuf[8] = values[0];
 	obuf[7] = command;
 
-	ret = af9005_usb_generic_rw(d, obuf, 16, ibuf, 17, 0);
+	ret = dvb_usb_generic_rw(d, obuf, 16, ibuf, 17, 0);
 	if (ret)
 		return ret;
 
@@ -537,7 +493,7 @@
 	buf[6] = wlen;
 	for (i = 0; i < wlen; i++)
 		buf[7 + i] = wbuf[i];
-	ret = af9005_usb_generic_rw(d, buf, wlen + 7, ibuf, rlen + 7, 0);
+	ret = dvb_usb_generic_rw(d, buf, wlen + 7, ibuf, rlen + 7, 0);
 	if (ret)
 		return ret;
 	if (ibuf[2] != 0x27) {
@@ -584,7 +540,7 @@
 
 	obuf[6] = len;
 	obuf[7] = address;
-	ret = af9005_usb_generic_rw(d, obuf, 16, ibuf, 14, 0);
+	ret = dvb_usb_generic_rw(d, obuf, 16, ibuf, 14, 0);
 	if (ret)
 		return ret;
 	if (ibuf[2] != 0x2b) {
@@ -885,7 +841,7 @@
 	obuf[2] = 0x40;		/* read remote */
 	obuf[3] = 1;		/* rest of packet length */
 	obuf[4] = st->sequence++;	/* sequence number */
-	ret = af9005_usb_generic_rw(d, obuf, 5, ibuf, 256, 0);
+	ret = dvb_usb_generic_rw(d, obuf, 5, ibuf, 256, 0);
 	if (ret) {
 		err("rc query failed");
 		return ret;
@@ -1077,6 +1033,9 @@
 	.rc_key_map_size = 0,
 	.rc_query = af9005_rc_query,
 
+	.generic_bulk_ctrl_endpoint          = 2,
+	.generic_bulk_ctrl_endpoint_response = 1,
+
 	.num_device_descs = 3,
 	.devices = {
 		    {.name = "Afatech DVB-T USB1.1 stick",

Re: [PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[Michael Krufky]

On Mon, Jun 21, 2010 at 1:29 AM, Michael Krufky <mkrufky@kernellabs.com> wrote:
> Could somebody please test this patch and confirm that it doesn't
> break the af9005 support?
>
> This patch removes the af9005_usb_generic_rw function and uses the
> dvb_usb_generic_rw function instead, using
> generic_bulk_ctrl_endpoint_response to differentiate between the read
> pipe and the write pipe.
>
> Also found in the mercurial repository:
>
> http://kernellabs.com/hg/~mkrufky/af9005
>
> Cheers,
>
> Mike Krufky

(patch inline this time)

# HG changeset patch
# User Michael Krufky <mkrufky@kernellabs.com>
# Date 1277095782 14400
# Node ID 8d43c09cfe26655166e7ab039f765223bc87f3c5
# Parent 723e03a57ef335a4e005ac57e49fa50d2c66a010
af9005: use generic_bulk_ctrl_endpoint_response

From: Michael Krufky <mkrufky@kernellabs.com>

Priority: normal

Signed-off-by: Michael Krufky <mkrufky@kernellabs.com>

--- a/linux/drivers/media/dvb/dvb-usb/af9005.c	Sun Jan 31 19:06:10 2010 -0500
+++ b/linux/drivers/media/dvb/dvb-usb/af9005.c	Mon Jun 21 00:49:42 2010 -0400
@@ -54,50 +54,6 @@
 	int led_state;
 };

-static int af9005_usb_generic_rw(struct dvb_usb_device *d, u8 *wbuf, u16 wlen,
-			  u8 *rbuf, u16 rlen, int delay_ms)
-{
-	int actlen, ret = -ENOMEM;
-
-	if (wbuf == NULL || wlen == 0)
-		return -EINVAL;
-
-	if ((ret = mutex_lock_interruptible(&d->usb_mutex)))
-		return ret;
-
-	deb_xfer(">>> ");
-	debug_dump(wbuf, wlen, deb_xfer);
-
-	ret = usb_bulk_msg(d->udev, usb_sndbulkpipe(d->udev,
-						    2), wbuf, wlen,
-			   &actlen, 2000);
-
-	if (ret)
-		err("bulk message failed: %d (%d/%d)", ret, wlen, actlen);
-	else
-		ret = actlen != wlen ? -1 : 0;
-
-	/* an answer is expected, and no error before */
-	if (!ret && rbuf && rlen) {
-		if (delay_ms)
-			msleep(delay_ms);
-
-		ret = usb_bulk_msg(d->udev, usb_rcvbulkpipe(d->udev,
-							    0x01), rbuf,
-				   rlen, &actlen, 2000);
-
-		if (ret)
-			err("recv bulk message failed: %d", ret);
-		else {
-			deb_xfer("<<< ");
-			debug_dump(rbuf, actlen, deb_xfer);
-		}
-	}
-
-	mutex_unlock(&d->usb_mutex);
-	return ret;
-}
-
 static int af9005_generic_read_write(struct dvb_usb_device *d, u16 reg,
 			      int readwrite, int type, u8 * values, int len)
 {
@@ -146,7 +102,7 @@
 		obuf[8] = values[0];
 	obuf[7] = command;

-	ret = af9005_usb_generic_rw(d, obuf, 16, ibuf, 17, 0);
+	ret = dvb_usb_generic_rw(d, obuf, 16, ibuf, 17, 0);
 	if (ret)
 		return ret;

@@ -537,7 +493,7 @@
 	buf[6] = wlen;
 	for (i = 0; i < wlen; i++)
 		buf[7 + i] = wbuf[i];
-	ret = af9005_usb_generic_rw(d, buf, wlen + 7, ibuf, rlen + 7, 0);
+	ret = dvb_usb_generic_rw(d, buf, wlen + 7, ibuf, rlen + 7, 0);
 	if (ret)
 		return ret;
 	if (ibuf[2] != 0x27) {
@@ -584,7 +540,7 @@

 	obuf[6] = len;
 	obuf[7] = address;
-	ret = af9005_usb_generic_rw(d, obuf, 16, ibuf, 14, 0);
+	ret = dvb_usb_generic_rw(d, obuf, 16, ibuf, 14, 0);
 	if (ret)
 		return ret;
 	if (ibuf[2] != 0x2b) {
@@ -885,7 +841,7 @@
 	obuf[2] = 0x40;		/* read remote */
 	obuf[3] = 1;		/* rest of packet length */
 	obuf[4] = st->sequence++;	/* sequence number */
-	ret = af9005_usb_generic_rw(d, obuf, 5, ibuf, 256, 0);
+	ret = dvb_usb_generic_rw(d, obuf, 5, ibuf, 256, 0);
 	if (ret) {
 		err("rc query failed");
 		return ret;
@@ -1077,6 +1033,9 @@
 	.rc_key_map_size = 0,
 	.rc_query = af9005_rc_query,

+	.generic_bulk_ctrl_endpoint          = 2,
+	.generic_bulk_ctrl_endpoint_response = 1,
+
 	.num_device_descs = 3,
 	.devices = {
 		    {.name = "Afatech DVB-T USB1.1 stick",

Re: [PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[Luca Olivetti]

En/na Michael Krufky ha escrit:
> Could somebody please test this patch and confirm that it doesn't
> break the af9005 support?
> 
> This patch removes the af9005_usb_generic_rw function and uses the
> dvb_usb_generic_rw function instead, using
> generic_bulk_ctrl_endpoint_response to differentiate between the read
> pipe and the write pipe.

Unfortunately I cannot test it (my device is broken)[*].
At the time I wrote my own rw function because I didn't find a way to 
send on a bulk endpoint and receiving on another one (i.e. I didn't know 
about generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or 
they weren't available at the time).

[*]Actually the tuner is broken, but the usb is working fine, so maybe I 
can give it a try.

Bye
-- 
Luca

Re: [PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[Michael Krufky]

On Mon, Jun 21, 2010 at 2:59 AM, Luca Olivetti <luca@ventoso.org> wrote:
> En/na Michael Krufky ha escrit:
>>
>> Could somebody please test this patch and confirm that it doesn't
>> break the af9005 support?
>>
>> This patch removes the af9005_usb_generic_rw function and uses the
>> dvb_usb_generic_rw function instead, using
>> generic_bulk_ctrl_endpoint_response to differentiate between the read
>> pipe and the write pipe.
>
> Unfortunately I cannot test it (my device is broken)[*].
> At the time I wrote my own rw function because I didn't find a way to send
> on a bulk endpoint and receiving on another one (i.e. I didn't know about
> generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they
> weren't available at the time).
>
> [*]Actually the tuner is broken, but the usb is working fine, so maybe I can
> give it a try.


Luca,

That's OK -- I only added this "generic_bulk_ctrl_endpoint_response"
feature 4 months ago -- your driver predates that.  I am pushing this
patch to reduce the size of the kernel while using your driver to
demonstrate how to use the new feature.  I am already using it in an
out of tree driver that I plan to merge within the next few months or
so, but its always nice to optimize code that already exists with
small cleanups like this.

You don't need the tuner in order to prove the patch -- if you can
simply confirm that you are able to both read and write successfully,
that would be enough to prove the patch.  After testing, please
provide an ack in this thread so that I may include that with my pull
request.

Thanks & regards,

Mike Krufky

Re: [PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[Luca Olivetti]

Al 21/06/10 17:45, En/na Michael Krufky ha escrit:
> On Mon, Jun 21, 2010 at 2:59 AM, Luca Olivetti<luca@ventoso.org>  wrote:
>> En/na Michael Krufky ha escrit:
>>>
>>> Could somebody please test this patch and confirm that it doesn't
>>> break the af9005 support?
>>>
>>> This patch removes the af9005_usb_generic_rw function and uses the
>>> dvb_usb_generic_rw function instead, using
>>> generic_bulk_ctrl_endpoint_response to differentiate between the read
>>> pipe and the write pipe.
>>
>> Unfortunately I cannot test it (my device is broken)[*].
>> At the time I wrote my own rw function because I didn't find a way to send
>> on a bulk endpoint and receiving on another one (i.e. I didn't know about
>> generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they
>> weren't available at the time).
>>
>> [*]Actually the tuner is broken, but the usb is working fine, so maybe I can
>> give it a try.
>
>
> Luca,
>
> That's OK -- I only added this "generic_bulk_ctrl_endpoint_response"
> feature 4 months ago -- your driver predates that.  I am pushing this
> patch to reduce the size of the kernel while using your driver to
> demonstrate how to use the new feature.  I am already using it in an
> out of tree driver that I plan to merge within the next few months or
> so, but its always nice to optimize code that already exists with
> small cleanups like this.
>
> You don't need the tuner in order to prove the patch -- if you can
> simply confirm that you are able to both read and write successfully,
> that would be enough to prove the patch.  After testing, please
> provide an ack in this thread so that I may include that with my pull
> request.

I cloned your hg tree and had to modify a couple of #if otherwise it 
wouldn't compile (it choked on dvb_class->nodename and 
dvb_class->devnode), after that it built fine and apparently the usb 
communication still works:

usb 8-2: new full speed USB device using uhci_hcd and address 2
usb 8-2: New USB device found, idVendor=15a4, idProduct=9020
usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 8-2: Product: DVBT
usb 8-2: Manufacturer: Afatech
usb 8-2: configuration #1 chosen from 1 choice
dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in cold state, will try to 
load a firmware
usb 8-2: firmware: requesting af9005.fw
dvb-usb: downloading firmware from file 'af9005.fw'
dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in warm state.
dvb-usb: will use the device's hardware PID filter (table count: 32).
DVB: registering new adapter (Afatech DVB-T USB1.1 stick)
DVB: registering adapter 0 frontend 0 (AF9005 USB DVB-T)...
input: IR-receiver inside an USB DVB receiver as 
/devices/pci0000:00/0000:00:1d.2/usb8/8-2/input/input12
dvb-usb: schedule remote query interval to 200 msecs.
dvb-usb: Afatech DVB-T USB1.1 stick successfully initialized and connected.
MT2060: successfully identified (IF1 = 1224)

Acked-by: Luca Olivetti <luca@ventoso.org>

Bye
-- 
Luca

Re: [PATCH] af9005: use generic_bulk_ctrl_endpoint_response

[Michael Krufky]

On Mon, Jun 21, 2010 at 2:22 PM, Luca Olivetti <luca@ventoso.org> wrote:
> Al 21/06/10 17:45, En/na Michael Krufky ha escrit:
>>
>> On Mon, Jun 21, 2010 at 2:59 AM, Luca Olivetti<luca@ventoso.org>  wrote:
>>>
>>> En/na Michael Krufky ha escrit:
>>>>
>>>> Could somebody please test this patch and confirm that it doesn't
>>>> break the af9005 support?
>>>>
>>>> This patch removes the af9005_usb_generic_rw function and uses the
>>>> dvb_usb_generic_rw function instead, using
>>>> generic_bulk_ctrl_endpoint_response to differentiate between the read
>>>> pipe and the write pipe.
>>>
>>> Unfortunately I cannot test it (my device is broken)[*].
>>> At the time I wrote my own rw function because I didn't find a way to
>>> send
>>> on a bulk endpoint and receiving on another one (i.e. I didn't know about
>>> generic_bulk_ctrl_endpoint/generic_bulk_ctrl_endpoint_response or they
>>> weren't available at the time).
>>>
>>> [*]Actually the tuner is broken, but the usb is working fine, so maybe I
>>> can
>>> give it a try.
>>
>>
>> Luca,
>>
>> That's OK -- I only added this "generic_bulk_ctrl_endpoint_response"
>> feature 4 months ago -- your driver predates that.  I am pushing this
>> patch to reduce the size of the kernel while using your driver to
>> demonstrate how to use the new feature.  I am already using it in an
>> out of tree driver that I plan to merge within the next few months or
>> so, but its always nice to optimize code that already exists with
>> small cleanups like this.
>>
>> You don't need the tuner in order to prove the patch -- if you can
>> simply confirm that you are able to both read and write successfully,
>> that would be enough to prove the patch.  After testing, please
>> provide an ack in this thread so that I may include that with my pull
>> request.
>
> I cloned your hg tree and had to modify a couple of #if otherwise it
> wouldn't compile (it choked on dvb_class->nodename and dvb_class->devnode),
> after that it built fine and apparently the usb communication still works:
>
> usb 8-2: new full speed USB device using uhci_hcd and address 2
> usb 8-2: New USB device found, idVendor=15a4, idProduct=9020
> usb 8-2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
> usb 8-2: Product: DVBT
> usb 8-2: Manufacturer: Afatech
> usb 8-2: configuration #1 chosen from 1 choice
> dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in cold state, will try to
> load a firmware
> usb 8-2: firmware: requesting af9005.fw
> dvb-usb: downloading firmware from file 'af9005.fw'
> dvb-usb: found a 'Afatech DVB-T USB1.1 stick' in warm state.
> dvb-usb: will use the device's hardware PID filter (table count: 32).
> DVB: registering new adapter (Afatech DVB-T USB1.1 stick)
> DVB: registering adapter 0 frontend 0 (AF9005 USB DVB-T)...
> input: IR-receiver inside an USB DVB receiver as
> /devices/pci0000:00/0000:00:1d.2/usb8/8-2/input/input12
> dvb-usb: schedule remote query interval to 200 msecs.
> dvb-usb: Afatech DVB-T USB1.1 stick successfully initialized and connected.
> MT2060: successfully identified (IF1 = 1224)
>
> Acked-by: Luca Olivetti <luca@ventoso.org>
>
> Bye
> --
> Luca

Thank you, Luca -- I'll add your ack now and send off a pull request.

Cheers,.

Mike Krufky