Re: [PATCH RFC] [media] dib0700: remove redundant else

2016-10-10 Thread Patrick Boettcher 
On Mon, 10 Oct 2016 06:30:35 -0300
Mauro Carvalho Chehab  wrote:
> >  drivers/media/usb/dvb-usb/dib0700_devices.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
> > b/drivers/media/usb/dvb-usb/dib0700_devices.c index
> > 0857b56..3cd8566 100644 ---
> > a/drivers/media/usb/dvb-usb/dib0700_devices.c +++
> > b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -1736,13 +1736,9
> > @@ static int dib809x_tuner_attach(struct dvb_usb_adapter *adap)
> > struct dib0700_adapter_state *st = adap->priv; struct i2c_adapter
> > *tun_i2c = st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe,
> > DIBX000_I2C_INTERFACE_TUNER, 1); 
> > -   if (adap->id == 0) {
> > -   if (dvb_attach(dib0090_register,
> > adap->fe_adap[0].fe, tun_i2c, _dib0090_config) == NULL)
> > -   return -ENODEV;
> > -   } else {
> > -   if (dvb_attach(dib0090_register,
> > adap->fe_adap[0].fe, tun_i2c, _dib0090_config) == NULL)
> > -   return -ENODEV;
> > -   }
> > +   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe,
> > +  tun_i2c, _dib0090_config) == NULL)
> > +   return -ENODEV;  
> 
> 
> I suspect that this patch is wrong. It should be, instead, using
> fe_adap[1] on the else.
> 
> Patrick,
> 
> Could you please take a look?

I think you're right, it should be fe_adap[1], but I have lost track of
these devices and don't know the correct answer.

However, this code was introduced by 

commit 91be260faaf8561dc51e72033c346f6ab28d40d8
Author: Nicolas Sugino 
Date:   Thu Nov 26 19:00:28 2015 -0200

[media] dib8000: Add support for Mygica/Geniatech S2870

MyGica/Geniatech S2870 is very similar to the S870 but with dual tuner. The 
card is recognised as Geniatech STK8096-PVR.

[mche...@osg.samsung.com: Fix some checkpatch.pl issues]
Signed-off-by: Nicolas Sugino 

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 7ed4964..ea0391e 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -1736,8 +1736,13 @@ static int dib809x_tuner_attach(struct dvb_usb_adapter 
*adap)
struct dib0700_adapter_state *st = adap->priv;
struct i2c_adapter *tun_i2c = 
st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe, 
DIBX000_I2C_INTERFACE_TUNER, 1);
 
-   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
-   return -ENODEV;
+   if (adap->id == 0) {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   } else {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   }
 
st->set_param_save = adap->fe_adap[0].fe->ops.tuner_ops.set_params;
adap->fe_adap[0].fe->ops.tuner_ops.set_params = 
dib8096_set_param_override;

[..]

Maybe Nicolas can help (and test).

--
Patrick.

Re: [PATCH RFC] [media] dib0700: remove redundant else

2016-10-10 Thread Patrick Boettcher 
On Mon, 10 Oct 2016 06:30:35 -0300
Mauro Carvalho Chehab  wrote:
> >  drivers/media/usb/dvb-usb/dib0700_devices.c | 10 +++---
> >  1 file changed, 3 insertions(+), 7 deletions(-)
> > 
> > diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
> > b/drivers/media/usb/dvb-usb/dib0700_devices.c index
> > 0857b56..3cd8566 100644 ---
> > a/drivers/media/usb/dvb-usb/dib0700_devices.c +++
> > b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -1736,13 +1736,9
> > @@ static int dib809x_tuner_attach(struct dvb_usb_adapter *adap)
> > struct dib0700_adapter_state *st = adap->priv; struct i2c_adapter
> > *tun_i2c = st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe,
> > DIBX000_I2C_INTERFACE_TUNER, 1); 
> > -   if (adap->id == 0) {
> > -   if (dvb_attach(dib0090_register,
> > adap->fe_adap[0].fe, tun_i2c, _dib0090_config) == NULL)
> > -   return -ENODEV;
> > -   } else {
> > -   if (dvb_attach(dib0090_register,
> > adap->fe_adap[0].fe, tun_i2c, _dib0090_config) == NULL)
> > -   return -ENODEV;
> > -   }
> > +   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe,
> > +  tun_i2c, _dib0090_config) == NULL)
> > +   return -ENODEV;  
> 
> 
> I suspect that this patch is wrong. It should be, instead, using
> fe_adap[1] on the else.
> 
> Patrick,
> 
> Could you please take a look?

I think you're right, it should be fe_adap[1], but I have lost track of
these devices and don't know the correct answer.

However, this code was introduced by 

commit 91be260faaf8561dc51e72033c346f6ab28d40d8
Author: Nicolas Sugino 
Date:   Thu Nov 26 19:00:28 2015 -0200

[media] dib8000: Add support for Mygica/Geniatech S2870

MyGica/Geniatech S2870 is very similar to the S870 but with dual tuner. The 
card is recognised as Geniatech STK8096-PVR.

[mche...@osg.samsung.com: Fix some checkpatch.pl issues]
Signed-off-by: Nicolas Sugino 

Signed-off-by: Mauro Carvalho Chehab 

diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c 
b/drivers/media/usb/dvb-usb/dib0700_devices.c
index 7ed4964..ea0391e 100644
--- a/drivers/media/usb/dvb-usb/dib0700_devices.c
+++ b/drivers/media/usb/dvb-usb/dib0700_devices.c
@@ -1736,8 +1736,13 @@ static int dib809x_tuner_attach(struct dvb_usb_adapter 
*adap)
struct dib0700_adapter_state *st = adap->priv;
struct i2c_adapter *tun_i2c = 
st->dib8000_ops.get_i2c_master(adap->fe_adap[0].fe, 
DIBX000_I2C_INTERFACE_TUNER, 1);
 
-   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
-   return -ENODEV;
+   if (adap->id == 0) {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   } else {
+   if (dvb_attach(dib0090_register, adap->fe_adap[0].fe, tun_i2c, 
_dib0090_config) == NULL)
+   return -ENODEV;
+   }
 
st->set_param_save = adap->fe_adap[0].fe->ops.tuner_ops.set_params;
adap->fe_adap[0].fe->ops.tuner_ops.set_params = 
dib8096_set_param_override;

[..]

Maybe Nicolas can help (and test).

--
Patrick.

Re: [PATCH 09/26] dibusb: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
>   sndbuf[1] = (addr << 1) | (wo ? 0 : 1);
>  
> - memcpy([2],wbuf,wlen);
> + memcpy([2], wbuf, wlen);
>  
>   if (!wo) {
> - sndbuf[wlen+2] = (rlen >> 8) & 0xff;
> - sndbuf[wlen+3] = rlen & 0xff;
> + sndbuf[wlen + 2] = (rlen >> 8) & 0xff;
> + sndbuf[wlen + 3] = rlen & 0xff;
>   }
>  
> - return dvb_usb_generic_rw(d,sndbuf,len,rbuf,rlen,0);
> + ret = dvb_usb_generic_rw(d, sndbuf, len, rbuf, rlen, 0);
> +
> +ret:
> + kfree(sndbuf);
> + return ret;
>  }
>  
>  /*
> @@ -320,11 +354,23 @@ EXPORT_SYMBOL(rc_map_dibusb_table);
>  
>  int dibusb_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
>  {
> - u8 key[5],cmd = DIBUSB_REQ_POLL_REMOTE;
> - dvb_usb_generic_rw(d,,1,key,5,0);
> - dvb_usb_nec_rc_key_to_event(d,key,event,state);
> - if (key[0] != 0)
> - deb_info("key: %*ph\n", 5, key);
> + u8 *buf;
> +
> + buf = kmalloc(5, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = DIBUSB_REQ_POLL_REMOTE;
> +
> + dvb_usb_generic_rw(d, buf, 1, buf, 5, 0);
> +
> + dvb_usb_nec_rc_key_to_event(d, buf, event, state);
> +
> + if (buf[0] != 0)
> + deb_info("key: %*ph\n", 5, buf);
> +
> + kfree(buf);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(dibusb_rc_query);
> diff --git a/drivers/media/usb/dvb-usb/dibusb.h
> b/drivers/media/usb/dvb-usb/dibusb.h index 3f82163d8ab8..42e9750393e5
> 100644 --- a/drivers/media/usb/dvb-usb/dibusb.h
> +++ b/drivers/media/usb/dvb-usb/dibusb.h
> @@ -96,10 +96,15 @@
>  #define DIBUSB_IOCTL_CMD_ENABLE_STREAM   0x01
>  #define DIBUSB_IOCTL_CMD_DISABLE_STREAM  0x02
>  
> +/* Max transfer size done by I2C transfer functions */
> +#define MAX_XFER_SIZE  64
> +
>  struct dibusb_state {
>   struct dib_fe_xfer_ops ops;
>   int mt2060_present;
>   u8 tuner_addr;
> +
> + unsigned char data[MAX_XFER_SIZE];
>  };
>  
>  struct dibusb_device_state {

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 09/26] dibusb: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
 memcpy([2],wbuf,wlen);
> + memcpy([2], wbuf, wlen);
>  
>   if (!wo) {
> - sndbuf[wlen+2] = (rlen >> 8) & 0xff;
> - sndbuf[wlen+3] = rlen & 0xff;
> + sndbuf[wlen + 2] = (rlen >> 8) & 0xff;
> + sndbuf[wlen + 3] = rlen & 0xff;
>   }
>  
> - return dvb_usb_generic_rw(d,sndbuf,len,rbuf,rlen,0);
> + ret = dvb_usb_generic_rw(d, sndbuf, len, rbuf, rlen, 0);
> +
> +ret:
> + kfree(sndbuf);
> + return ret;
>  }
>  
>  /*
> @@ -320,11 +354,23 @@ EXPORT_SYMBOL(rc_map_dibusb_table);
>  
>  int dibusb_rc_query(struct dvb_usb_device *d, u32 *event, int *state)
>  {
> - u8 key[5],cmd = DIBUSB_REQ_POLL_REMOTE;
> - dvb_usb_generic_rw(d,,1,key,5,0);
> - dvb_usb_nec_rc_key_to_event(d,key,event,state);
> - if (key[0] != 0)
> - deb_info("key: %*ph\n", 5, key);
> + u8 *buf;
> +
> + buf = kmalloc(5, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = DIBUSB_REQ_POLL_REMOTE;
> +
> + dvb_usb_generic_rw(d, buf, 1, buf, 5, 0);
> +
> + dvb_usb_nec_rc_key_to_event(d, buf, event, state);
> +
> + if (buf[0] != 0)
> + deb_info("key: %*ph\n", 5, buf);
> +
> + kfree(buf);
> +
>   return 0;
>  }
>  EXPORT_SYMBOL(dibusb_rc_query);
> diff --git a/drivers/media/usb/dvb-usb/dibusb.h
> b/drivers/media/usb/dvb-usb/dibusb.h index 3f82163d8ab8..42e9750393e5
> 100644 --- a/drivers/media/usb/dvb-usb/dibusb.h
> +++ b/drivers/media/usb/dvb-usb/dibusb.h
> @@ -96,10 +96,15 @@
>  #define DIBUSB_IOCTL_CMD_ENABLE_STREAM   0x01
>  #define DIBUSB_IOCTL_CMD_DISABLE_STREAM  0x02
>  
> +/* Max transfer size done by I2C transfer functions */
> +#define MAX_XFER_SIZE  64
> +
>  struct dibusb_state {
>   struct dib_fe_xfer_ops ops;
>   int mt2060_present;
>   u8 tuner_addr;
> +
> + unsigned char data[MAX_XFER_SIZE];
>  };
>  
>  struct dibusb_device_state {

Reviewed-By: Patrick Boettcher

Re: [PATCH 08/26] dib0700_core: don't use stack on I2C reads

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:18 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> Be sure that I2C reads won't use stack by passing
> a pointer to the state buffer, that we know it was
> allocated via kmalloc, instead of relying on the buffer
> allocated by an I2C client.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c | 27
> ++- 1 file changed, 26 insertions(+), 1
> deletion(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c index
> 515f89dba199..92d5408684ac 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_core.c +++
> b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -213,7 +213,7 @@ static
> int dib0700_i2c_xfer_new(struct i2c_adapter *adap, struct i2c_msg
> *msg, usb_rcvctrlpipe(d->udev, 0), REQUEST_NEW_I2C_READ,
>USB_TYPE_VENDOR |
> USB_DIR_IN,
> -  value, index,
> msg[i].buf,
> +  value, index,
> st->buf, msg[i].len,
>USB_CTRL_GET_TIMEOUT);
>   if (result < 0) {
> @@ -221,6 +221,14 @@ static int dib0700_i2c_xfer_new(struct
> i2c_adapter *adap, struct i2c_msg *msg, break;
>   }
>  
> + if (msg[i].len > sizeof(st->buf)) {
> + deb_info("buffer too small to fit %d
> bytes\n",
> +  msg[i].len);
> + return -EIO;
> + }
> +
> + memcpy(msg[i].buf, st->buf, msg[i].len);
> +
>   deb_data("<<< ");
>   debug_dump(msg[i].buf, msg[i].len, deb_data);
>  
> @@ -238,6 +246,13 @@ static int dib0700_i2c_xfer_new(struct
> i2c_adapter *adap, struct i2c_msg *msg, /* I2C ctrl + FE bus; */
>   st->buf[3] = ((gen_mode << 6) & 0xC0) |
>((bus_mode << 4) & 0x30);
> +
> + if (msg[i].len > sizeof(st->buf) - 4) {
> + deb_info("i2c message to big: %d\n",
> +  msg[i].len);
> + return -EIO;
> + }
> +
>   /* The Actual i2c payload */
>   memcpy(>buf[4], msg[i].buf, msg[i].len);
>  
> @@ -283,6 +298,11 @@ static int dib0700_i2c_xfer_legacy(struct
> i2c_adapter *adap, /* fill in the address */
>   st->buf[1] = msg[i].addr << 1;
>   /* fill the buffer */
> + if (msg[i].len > sizeof(st->buf) - 2) {
> + deb_info("i2c xfer to big: %d\n",
> + msg[i].len);
> + return -EIO;
> + }
>   memcpy(>buf[2], msg[i].buf, msg[i].len);
>  
>   /* write/read request */
> @@ -299,6 +319,11 @@ static int dib0700_i2c_xfer_legacy(struct
> i2c_adapter *adap, break;
>   }
>  
> + if (msg[i + 1].len > sizeof(st->buf)) {
> + deb_info("i2c xfer buffer to small
> for %d\n",
> + msg[i].len);
> + return -EIO;
> + }
>   memcpy(msg[i + 1].buf, st->buf, msg[i +
> 1].len); 
>   msg[i+1].len = len;

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 02/26] cinergyT2-core: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:12 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/cinergyT2-core.c | 45
> ++ 1 file changed, 27 insertions(+), 18
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c index
> 9fd1527494eb..91640c927776 100644 ---
> a/drivers/media/usb/dvb-usb/cinergyT2-core.c +++
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c @@ -41,6 +41,7 @@
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); 
>  struct cinergyt2_state {
>   u8 rc_counter;
> + unsigned char data[64];
>  };
>  
>  /* We are missing a release hook with usb_device data */
> @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties
> cinergyt2_properties; 
>  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap,
> int enable) {
> - char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER,
> enable ? 1 : 0 };
> - char result[64];
> - return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf),
> result,
> - sizeof(result), 0);
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
> +
> + st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> + st->data[1] = enable ? 1 : 0;
> +
> + return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
>  }
>  
>  static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
>  {
> - char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
> - char state[3];
> - return dvb_usb_generic_rw(d, buf, sizeof(buf), state,
> sizeof(state), 0);
> + struct cinergyt2_state *st = d->priv;
> +
> + st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
> + st->data[1] = enable ? 0 : 1;
> +
> + return dvb_usb_generic_rw(d, st->data, 2, st->data, 3, 0);
>  }
>  
>  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>  {
> - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> - char state[3];
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
>   int ret;
>  
>   adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>  
> - ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query),
> state,
> - sizeof(state), 0);
> + st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
> +
> + ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>   if (ret < 0) {
>   deb_rc("cinergyt2_power_ctrl() Failed to retrieve
> sleep " "state info\n");
> @@ -141,13 +149,14 @@ static int repeatable_keys[] = {
>  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event,
> int *state) {
>   struct cinergyt2_state *st = d->priv;
> - u8 key[5] = {0, 0, 0, 0, 0}, cmd =
> CINERGYT2_EP1_GET_RC_EVENTS; int i;
>  
>   *state = REMOTE_NO_KEY_PRESSED;
>  
> - dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> - if (key[4] == 0xff) {
> + st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
> +
> + dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
> + if (st->data[4] == 0xff) {
>   /* key repeat */
>   st->rc_counter++;
>   if (st->rc_counter > RC_REPEAT_DELAY) {
> @@ -166,13 +175,13 @@ static int cinergyt2_rc_query(struct
> dvb_usb_device *d, u32 *event, int *state) }
>  
>   /* hack to pass checksum on the custom field */
> - key[2] = ~key[1];
> - dvb_usb_nec_rc_key_to_event(d, key, event, state);
> - if (key[0] != 0) {
> + st->data[2] = ~st->data[1];
> + dvb_usb_nec_rc_key_to_event(d, st->data, event, state);
> + if (st->data[0] != 0) {
>   if (*event != d->last_event)
>   st->rc_counter = 0;
>  
> - deb_rc("key: %*ph\n", 5, key);
> + deb_rc("key: %*ph\n", 5, st->data);
>   }
>   return 0;
>  }

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 08/26] dib0700_core: don't use stack on I2C reads

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:18 -0300
Mauro Carvalho Chehab  wrote:

> Be sure that I2C reads won't use stack by passing
> a pointer to the state buffer, that we know it was
> allocated via kmalloc, instead of relying on the buffer
> allocated by an I2C client.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c | 27
> ++- 1 file changed, 26 insertions(+), 1
> deletion(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c index
> 515f89dba199..92d5408684ac 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_core.c +++
> b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -213,7 +213,7 @@ static
> int dib0700_i2c_xfer_new(struct i2c_adapter *adap, struct i2c_msg
> *msg, usb_rcvctrlpipe(d->udev, 0), REQUEST_NEW_I2C_READ,
>USB_TYPE_VENDOR |
> USB_DIR_IN,
> -  value, index,
> msg[i].buf,
> +  value, index,
> st->buf, msg[i].len,
>USB_CTRL_GET_TIMEOUT);
>   if (result < 0) {
> @@ -221,6 +221,14 @@ static int dib0700_i2c_xfer_new(struct
> i2c_adapter *adap, struct i2c_msg *msg, break;
>   }
>  
> + if (msg[i].len > sizeof(st->buf)) {
> + deb_info("buffer too small to fit %d
> bytes\n",
> +  msg[i].len);
> + return -EIO;
> + }
> +
> + memcpy(msg[i].buf, st->buf, msg[i].len);
> +
>   deb_data("<<< ");
>   debug_dump(msg[i].buf, msg[i].len, deb_data);
>  
> @@ -238,6 +246,13 @@ static int dib0700_i2c_xfer_new(struct
> i2c_adapter *adap, struct i2c_msg *msg, /* I2C ctrl + FE bus; */
>   st->buf[3] = ((gen_mode << 6) & 0xC0) |
>((bus_mode << 4) & 0x30);
> +
> + if (msg[i].len > sizeof(st->buf) - 4) {
> + deb_info("i2c message to big: %d\n",
> +  msg[i].len);
> + return -EIO;
> + }
> +
>   /* The Actual i2c payload */
>   memcpy(>buf[4], msg[i].buf, msg[i].len);
>  
> @@ -283,6 +298,11 @@ static int dib0700_i2c_xfer_legacy(struct
> i2c_adapter *adap, /* fill in the address */
>   st->buf[1] = msg[i].addr << 1;
>   /* fill the buffer */
> + if (msg[i].len > sizeof(st->buf) - 2) {
> + deb_info("i2c xfer to big: %d\n",
> + msg[i].len);
> + return -EIO;
> + }
>   memcpy(>buf[2], msg[i].buf, msg[i].len);
>  
>   /* write/read request */
> @@ -299,6 +319,11 @@ static int dib0700_i2c_xfer_legacy(struct
> i2c_adapter *adap, break;
>   }
>  
> + if (msg[i + 1].len > sizeof(st->buf)) {
> +     deb_info("i2c xfer buffer to small
> for %d\n",
> + msg[i].len);
> + return -EIO;
> + }
>   memcpy(msg[i + 1].buf, st->buf, msg[i +
> 1].len); 
>   msg[i+1].len = len;

Reviewed-By: Patrick Boettcher

Re: [PATCH 02/26] cinergyT2-core: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:12 -0300
Mauro Carvalho Chehab  wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/cinergyT2-core.c | 45
> ++ 1 file changed, 27 insertions(+), 18
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-core.c
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c index
> 9fd1527494eb..91640c927776 100644 ---
> a/drivers/media/usb/dvb-usb/cinergyT2-core.c +++
> b/drivers/media/usb/dvb-usb/cinergyT2-core.c @@ -41,6 +41,7 @@
> DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr); 
>  struct cinergyt2_state {
>   u8 rc_counter;
> + unsigned char data[64];
>  };
>  
>  /* We are missing a release hook with usb_device data */
> @@ -50,29 +51,36 @@ static struct dvb_usb_device_properties
> cinergyt2_properties; 
>  static int cinergyt2_streaming_ctrl(struct dvb_usb_adapter *adap,
> int enable) {
> - char buf[] = { CINERGYT2_EP1_CONTROL_STREAM_TRANSFER,
> enable ? 1 : 0 };
> - char result[64];
> - return dvb_usb_generic_rw(adap->dev, buf, sizeof(buf),
> result,
> - sizeof(result), 0);
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
> +
> + st->data[0] = CINERGYT2_EP1_CONTROL_STREAM_TRANSFER;
> + st->data[1] = enable ? 1 : 0;
> +
> + return dvb_usb_generic_rw(d, st->data, 2, st->data, 64, 0);
>  }
>  
>  static int cinergyt2_power_ctrl(struct dvb_usb_device *d, int enable)
>  {
> - char buf[] = { CINERGYT2_EP1_SLEEP_MODE, enable ? 0 : 1 };
> - char state[3];
> - return dvb_usb_generic_rw(d, buf, sizeof(buf), state,
> sizeof(state), 0);
> + struct cinergyt2_state *st = d->priv;
> +
> + st->data[0] = CINERGYT2_EP1_SLEEP_MODE;
> + st->data[1] = enable ? 0 : 1;
> +
> + return dvb_usb_generic_rw(d, st->data, 2, st->data, 3, 0);
>  }
>  
>  static int cinergyt2_frontend_attach(struct dvb_usb_adapter *adap)
>  {
> - char query[] = { CINERGYT2_EP1_GET_FIRMWARE_VERSION };
> - char state[3];
> + struct dvb_usb_device *d = adap->dev;
> + struct cinergyt2_state *st = d->priv;
>   int ret;
>  
>   adap->fe_adap[0].fe = cinergyt2_fe_attach(adap->dev);
>  
> - ret = dvb_usb_generic_rw(adap->dev, query, sizeof(query),
> state,
> - sizeof(state), 0);
> + st->data[0] = CINERGYT2_EP1_GET_FIRMWARE_VERSION;
> +
> + ret = dvb_usb_generic_rw(d, st->data, 1, st->data, 3, 0);
>   if (ret < 0) {
>   deb_rc("cinergyt2_power_ctrl() Failed to retrieve
> sleep " "state info\n");
> @@ -141,13 +149,14 @@ static int repeatable_keys[] = {
>  static int cinergyt2_rc_query(struct dvb_usb_device *d, u32 *event,
> int *state) {
>   struct cinergyt2_state *st = d->priv;
> - u8 key[5] = {0, 0, 0, 0, 0}, cmd =
> CINERGYT2_EP1_GET_RC_EVENTS; int i;
>  
>   *state = REMOTE_NO_KEY_PRESSED;
>  
> - dvb_usb_generic_rw(d, , 1, key, sizeof(key), 0);
> - if (key[4] == 0xff) {
> + st->data[0] = CINERGYT2_EP1_GET_RC_EVENTS;
> +
> + dvb_usb_generic_rw(d, st->data, 1, st->data, 5, 0);
> + if (st->data[4] == 0xff) {
>   /* key repeat */
>   st->rc_counter++;
>   if (st->rc_counter > RC_REPEAT_DELAY) {
> @@ -166,13 +175,13 @@ static int cinergyt2_rc_query(struct
> dvb_usb_device *d, u32 *event, int *state) }
>  
>   /* hack to pass checksum on the custom field */
> - key[2] = ~key[1];
> - dvb_usb_nec_rc_key_to_event(d, key, event, state);
> - if (key[0] != 0) {
> + st->data[2] = ~st->data[1];
> + dvb_usb_nec_rc_key_to_event(d, st->data, event, state);
> + if (st->data[0] != 0) {
>   if (*event != d->last_event)
>   st->rc_counter = 0;
>  
> - deb_rc("key: %*ph\n", 5, key);
> + deb_rc("key: %*ph\n", 5, st->data);
>   }
>   return 0;
>  }

Reviewed-By: Patrick Boettcher

Re: [PATCH 05/26] cinergyT2-fe: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:15 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/cinergyT2-fe.c | 45
>  1 file changed, 23 insertions(+), 22
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-fe.c
> b/drivers/media/usb/dvb-usb/cinergyT2-fe.c index
> fd8edcb56e61..03ba66ef1f28 100644 ---
> a/drivers/media/usb/dvb-usb/cinergyT2-fe.c +++
> b/drivers/media/usb/dvb-usb/cinergyT2-fe.c @@ -139,6 +139,9 @@ static
> uint16_t compute_tps(struct dtv_frontend_properties *op) struct
> cinergyt2_fe_state { struct dvb_frontend fe;
>   struct dvb_usb_device *d;
> +
> + unsigned char data[64];
> +
>   struct dvbt_get_status_msg status;
>  };
>  
> @@ -146,28 +149,28 @@ static int cinergyt2_fe_read_status(struct
> dvb_frontend *fe, enum fe_status *status)
>  {
>   struct cinergyt2_fe_state *state = fe->demodulator_priv;
> - struct dvbt_get_status_msg result;
> - u8 cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
>   int ret;
>  
> - ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (u8
> *),
> - sizeof(result), 0);
> + state->data[0] = CINERGYT2_EP1_GET_TUNER_STATUS;
> +
> + ret = dvb_usb_generic_rw(state->d, state->data, 1,
> +  state->data, sizeof(state->status),
> 0); if (ret < 0)
>   return ret;
>  
> - state->status = result;
> + memcpy(>status, state->data, sizeof(state->status));
>  
>   *status = 0;
>  
> - if (0x - le16_to_cpu(result.gain) > 30)
> + if (0x - le16_to_cpu(state->status.gain) > 30)
>   *status |= FE_HAS_SIGNAL;
> - if (result.lock_bits & (1 << 6))
> + if (state->status.lock_bits & (1 << 6))
>   *status |= FE_HAS_LOCK;
> - if (result.lock_bits & (1 << 5))
> + if (state->status.lock_bits & (1 << 5))
>   *status |= FE_HAS_SYNC;
> - if (result.lock_bits & (1 << 4))
> + if (state->status.lock_bits & (1 << 4))
>   *status |= FE_HAS_CARRIER;
> - if (result.lock_bits & (1 << 1))
> + if (state->status.lock_bits & (1 << 1))
>   *status |= FE_HAS_VITERBI;
>  
>   if ((*status & (FE_HAS_CARRIER | FE_HAS_VITERBI |
> FE_HAS_SYNC)) != @@ -232,31 +235,29 @@ static int
> cinergyt2_fe_set_frontend(struct dvb_frontend *fe) {
>   struct dtv_frontend_properties *fep =
> >dtv_property_cache; struct cinergyt2_fe_state *state =
> fe->demodulator_priv;
> - struct dvbt_set_parameters_msg param;
> - char result[2];
> + struct dvbt_set_parameters_msg *param = (void *)state->data;
>   int err;
>  
> - param.cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
> - param.tps = cpu_to_le16(compute_tps(fep));
> - param.freq = cpu_to_le32(fep->frequency / 1000);
> - param.flags = 0;
> + param->cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
> + param->tps = cpu_to_le16(compute_tps(fep));
> + param->freq = cpu_to_le32(fep->frequency / 1000);
> + param->flags = 0;
>  
>   switch (fep->bandwidth_hz) {
>   default:
>   case 800:
> - param.bandwidth = 8;
> + param->bandwidth = 8;
>   break;
>   case 700:
> - param.bandwidth = 7;
> + param->bandwidth = 7;
>   break;
>   case 600:
> - param.bandwidth = 6;
> + param->bandwidth = 6;
>   break;
>   }
>  
> - err = dvb_usb_generic_rw(state->d,
> - (char *), sizeof(param),
> - result, sizeof(result), 0);
> + err = dvb_usb_generic_rw(state->d, state->data,
> sizeof(*param),
> +  state->data, 2, 0);
>   if (err < 0)
>   err("cinergyt2_fe_set_frontend() Failed! err=%d\n",
> err); 

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 05/26] cinergyT2-fe: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:15 -0300
Mauro Carvalho Chehab  wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/cinergyT2-fe.c | 45
>  1 file changed, 23 insertions(+), 22
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cinergyT2-fe.c
> b/drivers/media/usb/dvb-usb/cinergyT2-fe.c index
> fd8edcb56e61..03ba66ef1f28 100644 ---
> a/drivers/media/usb/dvb-usb/cinergyT2-fe.c +++
> b/drivers/media/usb/dvb-usb/cinergyT2-fe.c @@ -139,6 +139,9 @@ static
> uint16_t compute_tps(struct dtv_frontend_properties *op) struct
> cinergyt2_fe_state { struct dvb_frontend fe;
>   struct dvb_usb_device *d;
> +
> + unsigned char data[64];
> +
>   struct dvbt_get_status_msg status;
>  };
>  
> @@ -146,28 +149,28 @@ static int cinergyt2_fe_read_status(struct
> dvb_frontend *fe, enum fe_status *status)
>  {
>   struct cinergyt2_fe_state *state = fe->demodulator_priv;
> - struct dvbt_get_status_msg result;
> - u8 cmd[] = { CINERGYT2_EP1_GET_TUNER_STATUS };
>   int ret;
>  
> - ret = dvb_usb_generic_rw(state->d, cmd, sizeof(cmd), (u8
> *),
> - sizeof(result), 0);
> + state->data[0] = CINERGYT2_EP1_GET_TUNER_STATUS;
> +
> + ret = dvb_usb_generic_rw(state->d, state->data, 1,
> +  state->data, sizeof(state->status),
> 0); if (ret < 0)
>   return ret;
>  
> - state->status = result;
> + memcpy(>status, state->data, sizeof(state->status));
>  
>   *status = 0;
>  
> - if (0x - le16_to_cpu(result.gain) > 30)
> + if (0x - le16_to_cpu(state->status.gain) > 30)
>   *status |= FE_HAS_SIGNAL;
> - if (result.lock_bits & (1 << 6))
> + if (state->status.lock_bits & (1 << 6))
>   *status |= FE_HAS_LOCK;
> - if (result.lock_bits & (1 << 5))
> + if (state->status.lock_bits & (1 << 5))
>   *status |= FE_HAS_SYNC;
> - if (result.lock_bits & (1 << 4))
> + if (state->status.lock_bits & (1 << 4))
>   *status |= FE_HAS_CARRIER;
> - if (result.lock_bits & (1 << 1))
> + if (state->status.lock_bits & (1 << 1))
>   *status |= FE_HAS_VITERBI;
>  
>   if ((*status & (FE_HAS_CARRIER | FE_HAS_VITERBI |
> FE_HAS_SYNC)) != @@ -232,31 +235,29 @@ static int
> cinergyt2_fe_set_frontend(struct dvb_frontend *fe) {
>   struct dtv_frontend_properties *fep =
> >dtv_property_cache; struct cinergyt2_fe_state *state =
> fe->demodulator_priv;
> - struct dvbt_set_parameters_msg param;
> - char result[2];
> + struct dvbt_set_parameters_msg *param = (void *)state->data;
>   int err;
>  
> - param.cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
> - param.tps = cpu_to_le16(compute_tps(fep));
> - param.freq = cpu_to_le32(fep->frequency / 1000);
> - param.flags = 0;
> + param->cmd = CINERGYT2_EP1_SET_TUNER_PARAMETERS;
> + param->tps = cpu_to_le16(compute_tps(fep));
> + param->freq = cpu_to_le32(fep->frequency / 1000);
> + param->flags = 0;
>  
>   switch (fep->bandwidth_hz) {
>   default:
>   case 800:
> - param.bandwidth = 8;
> + param->bandwidth = 8;
>   break;
>   case 700:
> - param.bandwidth = 7;
> + param->bandwidth = 7;
>   break;
>   case 600:
> - param.bandwidth = 6;
> +     param->bandwidth = 6;
>   break;
>   }
>  
> - err = dvb_usb_generic_rw(state->d,
> - (char *), sizeof(param),
> - result, sizeof(result), 0);
> + err = dvb_usb_generic_rw(state->d, state->data,
> sizeof(*param),
> +  state->data, 2, 0);
>   if (err < 0)
>   err("cinergyt2_fe_set_frontend() Failed! err=%d\n",
> err); 

Reviewed-By: Patrick Boettcher

Re: [PATCH 06/26] cxusb: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:16 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/cxusb.c | 20 +++-
>  drivers/media/usb/dvb-usb/cxusb.h |  5 +
>  2 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cxusb.c
> b/drivers/media/usb/dvb-usb/cxusb.c index 907ac01ae297..f3615349de52
> 100644 --- a/drivers/media/usb/dvb-usb/cxusb.c
> +++ b/drivers/media/usb/dvb-usb/cxusb.c
> @@ -45,9 +45,6 @@
>  #include "si2168.h"
>  #include "si2157.h"
>  
> -/* Max transfer size done by I2C transfer functions */
> -#define MAX_XFER_SIZE  80
> -
>  /* debug */
>  static int dvb_usb_cxusb_debug;
>  module_param_named(debug, dvb_usb_cxusb_debug, int, 0644);
> @@ -61,23 +58,20 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  static int cxusb_ctrl_msg(struct dvb_usb_device *d,
> u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int
> rlen) {
> + struct cxusb_state *st = d->priv;
>   int wo = (rbuf == NULL || rlen == 0); /* write-only */
> - u8 sndbuf[MAX_XFER_SIZE];
>  
> - if (1 + wlen > sizeof(sndbuf)) {
> - warn("i2c wr: len=%d is too big!\n",
> -  wlen);
> + if (1 + wlen > MAX_XFER_SIZE) {
> + warn("i2c wr: len=%d is too big!\n", wlen);
>   return -EOPNOTSUPP;
>   }
>  
> - memset(sndbuf, 0, 1+wlen);
> -
> - sndbuf[0] = cmd;
> - memcpy([1], wbuf, wlen);
> + st->data[0] = cmd;
> + memcpy(>data[1], wbuf, wlen);
>   if (wo)
> - return dvb_usb_generic_write(d, sndbuf, 1+wlen);
> + return dvb_usb_generic_write(d, st->data, 1 + wlen);
>   else
> - return dvb_usb_generic_rw(d, sndbuf, 1+wlen, rbuf,
> rlen, 0);
> + return dvb_usb_generic_rw(d, st->data, 1 + wlen,
> rbuf, rlen, 0); }
>  
>  /* GPIO */
> diff --git a/drivers/media/usb/dvb-usb/cxusb.h
> b/drivers/media/usb/dvb-usb/cxusb.h index 527ff7905e15..18acda19527a
> 100644 --- a/drivers/media/usb/dvb-usb/cxusb.h
> +++ b/drivers/media/usb/dvb-usb/cxusb.h
> @@ -28,10 +28,15 @@
>  #define CMD_ANALOG0x50
>  #define CMD_DIGITAL   0x51
>  
> +/* Max transfer size done by I2C transfer functions */
> +#define MAX_XFER_SIZE  80
> +
>  struct cxusb_state {
>   u8 gpio_write_state[3];
>   struct i2c_client *i2c_client_demod;
>   struct i2c_client *i2c_client_tuner;
> +
> + unsigned char data[MAX_XFER_SIZE];
>  };
>  
>  #endif

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 07/26] dib0700: be sure that dib0700_ctrl_rd() users can do DMA

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:17 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> dib0700_ctrl_rd() takes a RX and a TX pointer. Be sure that
> both will point to a memory allocated via kmalloc().
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c|  4 +++-
>  drivers/media/usb/dvb-usb/dib0700_devices.c | 25
> + 2 files changed, 16 insertions(+), 13
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c index
> f3196658fb70..515f89dba199 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_core.c +++
> b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -292,13 +292,15 @@
> static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap, 
>   /* special thing in the current firmware:
> when length is zero the read-failed */ len = dib0700_ctrl_rd(d,
> st->buf, msg[i].len + 2,
> - msg[i+1].buf, msg[i+1].len);
> +   st->buf, msg[i +
> 1].len); if (len <= 0) {
>   deb_info("I2C read failed on address
> 0x%02x\n", msg[i].addr);
>   break;
>   }
>  
> + memcpy(msg[i + 1].buf, st->buf, msg[i +
> 1].len); +
>   msg[i+1].len = len;
>  
>   i++;
> diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
> b/drivers/media/usb/dvb-usb/dib0700_devices.c index
> 0857b56e652c..ef1b8ee75c57 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_devices.c +++
> b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -508,8 +508,6 @@
> static int stk7700ph_tuner_attach(struct dvb_usb_adapter *adap) 
>  #define DEFAULT_RC_INTERVAL 50
>  
> -static u8 rc_request[] = { REQUEST_POLL_RC, 0 };
> -
>  /*
>   * This function is used only when firmware is < 1.20 version. Newer
>   * firmwares use bulk mode, with functions implemented at
> dib0700_core, @@ -517,7 +515,6 @@ static u8 rc_request[] =
> { REQUEST_POLL_RC, 0 }; */
>  static int dib0700_rc_query_old_firmware(struct dvb_usb_device *d)
>  {
> - u8 key[4];
>   enum rc_type protocol;
>   u32 scancode;
>   u8 toggle;
> @@ -532,39 +529,43 @@ static int dib0700_rc_query_old_firmware(struct
> dvb_usb_device *d) return 0;
>   }
>  
> - i = dib0700_ctrl_rd(d, rc_request, 2, key, 4);
> + st->buf[0] = REQUEST_POLL_RC;
> + st->buf[1] = 0;
> +
> + i = dib0700_ctrl_rd(d, st->buf, 2, st->buf, 4);
>   if (i <= 0) {
>   err("RC Query Failed");
> - return -1;
> + return -EIO;
>   }
>  
>   /* losing half of KEY_0 events from Philipps rc5 remotes.. */
> - if (key[0] == 0 && key[1] == 0 && key[2] == 0 && key[3] == 0)
> + if (st->buf[0] == 0 && st->buf[1] == 0
> + && st->buf[2] == 0 && st->buf[3] == 0)
>   return 0;
>  
> - /* info("%d: %2X %2X %2X
> %2X",dvb_usb_dib0700_ir_proto,(int)key[3-2],(int)key[3-3],(int)key[3-1],(int)key[3]);
> */
> + /* info("%d: %2X %2X %2X
> %2X",dvb_usb_dib0700_ir_proto,(int)st->buf[3 - 2],(int)st->buf[3 -
> 3],(int)st->buf[3 - 1],(int)st->buf[3]);  */ dib0700_rc_setup(d,
> NULL); /* reset ir sensor data to prevent false events */ 
>   switch (d->props.rc.core.protocol) {
>   case RC_BIT_NEC:
>   /* NEC protocol sends repeat code as 0 0 0 FF */
> - if ((key[3-2] == 0x00) && (key[3-3] == 0x00) &&
> - (key[3] == 0xff)) {
> + if ((st->buf[3 - 2] == 0x00) && (st->buf[3 - 3] ==
> 0x00) &&
> + (st->buf[3] == 0xff)) {
>   rc_repeat(d->rc_dev);
>   return 0;
>   }
>  
>   protocol = RC_TYPE_NEC;
> - scancode = RC_SCANCODE_NEC(key[3-2], key[3-3]);
> + scancode = RC_SCANCODE_NEC(st->buf[3 - 2], st->buf[3
> - 3]); toggle = 0;
>   break;
>  
>   default:
>   /* RC-5 protocol changes toggle bit on new keypress
> */ protocol = RC_TYPE_RC5;
> - scancode = RC_SCANCODE_RC5(key[3-2], key[3-3]);
> - toggle = key[3-1];
> + scancode = RC_SCANCODE_RC5(st->buf[3 - 2], st->buf[3
> - 3]);
> + toggle = st->buf[3 - 1];
>   break;
>   }
>  

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 06/26] cxusb: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:16 -0300
Mauro Carvalho Chehab  wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/cxusb.c | 20 +++-
>  drivers/media/usb/dvb-usb/cxusb.h |  5 +
>  2 files changed, 12 insertions(+), 13 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/cxusb.c
> b/drivers/media/usb/dvb-usb/cxusb.c index 907ac01ae297..f3615349de52
> 100644 --- a/drivers/media/usb/dvb-usb/cxusb.c
> +++ b/drivers/media/usb/dvb-usb/cxusb.c
> @@ -45,9 +45,6 @@
>  #include "si2168.h"
>  #include "si2157.h"
>  
> -/* Max transfer size done by I2C transfer functions */
> -#define MAX_XFER_SIZE  80
> -
>  /* debug */
>  static int dvb_usb_cxusb_debug;
>  module_param_named(debug, dvb_usb_cxusb_debug, int, 0644);
> @@ -61,23 +58,20 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  static int cxusb_ctrl_msg(struct dvb_usb_device *d,
> u8 cmd, u8 *wbuf, int wlen, u8 *rbuf, int
> rlen) {
> + struct cxusb_state *st = d->priv;
>   int wo = (rbuf == NULL || rlen == 0); /* write-only */
> - u8 sndbuf[MAX_XFER_SIZE];
>  
> - if (1 + wlen > sizeof(sndbuf)) {
> - warn("i2c wr: len=%d is too big!\n",
> -  wlen);
> + if (1 + wlen > MAX_XFER_SIZE) {
> + warn("i2c wr: len=%d is too big!\n", wlen);
>   return -EOPNOTSUPP;
>   }
>  
> - memset(sndbuf, 0, 1+wlen);
> -
> - sndbuf[0] = cmd;
> - memcpy([1], wbuf, wlen);
> + st->data[0] = cmd;
> + memcpy(>data[1], wbuf, wlen);
>   if (wo)
> - return dvb_usb_generic_write(d, sndbuf, 1+wlen);
> + return dvb_usb_generic_write(d, st->data, 1 + wlen);
>   else
> - return dvb_usb_generic_rw(d, sndbuf, 1+wlen, rbuf,
> rlen, 0);
> + return dvb_usb_generic_rw(d, st->data, 1 + wlen,
> rbuf, rlen, 0); }
>  
>  /* GPIO */
> diff --git a/drivers/media/usb/dvb-usb/cxusb.h
> b/drivers/media/usb/dvb-usb/cxusb.h index 527ff7905e15..18acda19527a
> 100644 --- a/drivers/media/usb/dvb-usb/cxusb.h
> +++ b/drivers/media/usb/dvb-usb/cxusb.h
> @@ -28,10 +28,15 @@
>  #define CMD_ANALOG0x50
>  #define CMD_DIGITAL   0x51
>  
> +/* Max transfer size done by I2C transfer functions */
> +#define MAX_XFER_SIZE  80
> +
>  struct cxusb_state {
>   u8 gpio_write_state[3];
>   struct i2c_client *i2c_client_demod;
>   struct i2c_client *i2c_client_tuner;
> +
> + unsigned char data[MAX_XFER_SIZE];
>  };
>  
>  #endif

Reviewed-By: Patrick Boettcher

Re: [PATCH 07/26] dib0700: be sure that dib0700_ctrl_rd() users can do DMA

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:17 -0300
Mauro Carvalho Chehab  wrote:

> dib0700_ctrl_rd() takes a RX and a TX pointer. Be sure that
> both will point to a memory allocated via kmalloc().
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/dib0700_core.c|  4 +++-
>  drivers/media/usb/dvb-usb/dib0700_devices.c | 25
> + 2 files changed, 16 insertions(+), 13
> deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/dib0700_core.c
> b/drivers/media/usb/dvb-usb/dib0700_core.c index
> f3196658fb70..515f89dba199 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_core.c +++
> b/drivers/media/usb/dvb-usb/dib0700_core.c @@ -292,13 +292,15 @@
> static int dib0700_i2c_xfer_legacy(struct i2c_adapter *adap, 
>   /* special thing in the current firmware:
> when length is zero the read-failed */ len = dib0700_ctrl_rd(d,
> st->buf, msg[i].len + 2,
> - msg[i+1].buf, msg[i+1].len);
> +   st->buf, msg[i +
> 1].len); if (len <= 0) {
>   deb_info("I2C read failed on address
> 0x%02x\n", msg[i].addr);
>   break;
>   }
>  
> + memcpy(msg[i + 1].buf, st->buf, msg[i +
> 1].len); +
>   msg[i+1].len = len;
>  
>   i++;
> diff --git a/drivers/media/usb/dvb-usb/dib0700_devices.c
> b/drivers/media/usb/dvb-usb/dib0700_devices.c index
> 0857b56e652c..ef1b8ee75c57 100644 ---
> a/drivers/media/usb/dvb-usb/dib0700_devices.c +++
> b/drivers/media/usb/dvb-usb/dib0700_devices.c @@ -508,8 +508,6 @@
> static int stk7700ph_tuner_attach(struct dvb_usb_adapter *adap) 
>  #define DEFAULT_RC_INTERVAL 50
>  
> -static u8 rc_request[] = { REQUEST_POLL_RC, 0 };
> -
>  /*
>   * This function is used only when firmware is < 1.20 version. Newer
>   * firmwares use bulk mode, with functions implemented at
> dib0700_core, @@ -517,7 +515,6 @@ static u8 rc_request[] =
> { REQUEST_POLL_RC, 0 }; */
>  static int dib0700_rc_query_old_firmware(struct dvb_usb_device *d)
>  {
> - u8 key[4];
>   enum rc_type protocol;
>   u32 scancode;
>   u8 toggle;
> @@ -532,39 +529,43 @@ static int dib0700_rc_query_old_firmware(struct
> dvb_usb_device *d) return 0;
>   }
>  
> - i = dib0700_ctrl_rd(d, rc_request, 2, key, 4);
> + st->buf[0] = REQUEST_POLL_RC;
> + st->buf[1] = 0;
> +
> + i = dib0700_ctrl_rd(d, st->buf, 2, st->buf, 4);
>   if (i <= 0) {
>   err("RC Query Failed");
> - return -1;
> + return -EIO;
>   }
>  
>   /* losing half of KEY_0 events from Philipps rc5 remotes.. */
> - if (key[0] == 0 && key[1] == 0 && key[2] == 0 && key[3] == 0)
> + if (st->buf[0] == 0 && st->buf[1] == 0
> + && st->buf[2] == 0 && st->buf[3] == 0)
>   return 0;
>  
> - /* info("%d: %2X %2X %2X
> %2X",dvb_usb_dib0700_ir_proto,(int)key[3-2],(int)key[3-3],(int)key[3-1],(int)key[3]);
> */
> + /* info("%d: %2X %2X %2X
> %2X",dvb_usb_dib0700_ir_proto,(int)st->buf[3 - 2],(int)st->buf[3 -
> 3],(int)st->buf[3 - 1],(int)st->buf[3]);  */ dib0700_rc_setup(d,
> NULL); /* reset ir sensor data to prevent false events */ 
>   switch (d->props.rc.core.protocol) {
>   case RC_BIT_NEC:
>   /* NEC protocol sends repeat code as 0 0 0 FF */
> - if ((key[3-2] == 0x00) && (key[3-3] == 0x00) &&
> - (key[3] == 0xff)) {
> + if ((st->buf[3 - 2] == 0x00) && (st->buf[3 - 3] ==
> 0x00) &&
> + (st->buf[3] == 0xff)) {
>   rc_repeat(d->rc_dev);
>   return 0;
>   }
>  
>   protocol = RC_TYPE_NEC;
> - scancode = RC_SCANCODE_NEC(key[3-2], key[3-3]);
> + scancode = RC_SCANCODE_NEC(st->buf[3 - 2], st->buf[3
> - 3]); toggle = 0;
>   break;
>  
>   default:
>   /* RC-5 protocol changes toggle bit on new keypress
> */ protocol = RC_TYPE_RC5;
> - scancode = RC_SCANCODE_RC5(key[3-2], key[3-3]);
> - toggle = key[3-1];
> + scancode = RC_SCANCODE_RC5(st->buf[3 - 2], st->buf[3
> - 3]);
> + toggle = st->buf[3 - 1];
>   break;
>   }
>  

Reviewed-By: Patrick Boettcher

Re: [PATCH 11/26] digitv: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:21 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/digitv.c | 20 +++-
>  drivers/media/usb/dvb-usb/digitv.h |  3 +++
>  2 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/digitv.c
> b/drivers/media/usb/dvb-usb/digitv.c index 63134335c994..09f8c28bd4db
> 100644 --- a/drivers/media/usb/dvb-usb/digitv.c
> +++ b/drivers/media/usb/dvb-usb/digitv.c
> @@ -28,20 +28,22 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  static int digitv_ctrl_msg(struct dvb_usb_device *d,
>   u8 cmd, u8 vv, u8 *wbuf, int wlen, u8 *rbuf, int
> rlen) {
> + struct digitv_state *st = d->priv;
>   int wo = (rbuf == NULL || rlen == 0); /* write-only */
> - u8 sndbuf[7],rcvbuf[7];
> - memset(sndbuf,0,7); memset(rcvbuf,0,7);
>  
> - sndbuf[0] = cmd;
> - sndbuf[1] = vv;
> - sndbuf[2] = wo ? wlen : rlen;
> + memset(st->sndbuf, 0, 7);
> + memset(st->rcvbuf, 0, 7);
> +
> + st->sndbuf[0] = cmd;
> + st->sndbuf[1] = vv;
> + st->sndbuf[2] = wo ? wlen : rlen;
>  
>   if (wo) {
> - memcpy([3],wbuf,wlen);
> - dvb_usb_generic_write(d,sndbuf,7);
> + memcpy(>sndbuf[3], wbuf, wlen);
> + dvb_usb_generic_write(d, st->sndbuf, 7);
>   } else {
> - dvb_usb_generic_rw(d,sndbuf,7,rcvbuf,7,10);
> - memcpy(rbuf,[3],rlen);
> + dvb_usb_generic_rw(d, st->sndbuf, 7, st->rcvbuf, 7,
> 10);
> + memcpy(rbuf, >rcvbuf[3], rlen);
>   }
>   return 0;
>  }
> diff --git a/drivers/media/usb/dvb-usb/digitv.h
> b/drivers/media/usb/dvb-usb/digitv.h index 908c09f4966b..cf104689bdff
> 100644 --- a/drivers/media/usb/dvb-usb/digitv.h
> +++ b/drivers/media/usb/dvb-usb/digitv.h
> @@ -6,6 +6,9 @@
>  
>  struct digitv_state {
>  int is_nxt6000;
> +
> +unsigned char sndbuf[7];
> +unsigned char rcvbuf[7];
>  };
>  
>  /* protocol (from usblogging and the SDK:

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 11/26] digitv: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:21 -0300
Mauro Carvalho Chehab  wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/digitv.c | 20 +++-
>  drivers/media/usb/dvb-usb/digitv.h |  3 +++
>  2 files changed, 14 insertions(+), 9 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/digitv.c
> b/drivers/media/usb/dvb-usb/digitv.c index 63134335c994..09f8c28bd4db
> 100644 --- a/drivers/media/usb/dvb-usb/digitv.c
> +++ b/drivers/media/usb/dvb-usb/digitv.c
> @@ -28,20 +28,22 @@ DVB_DEFINE_MOD_OPT_ADAPTER_NR(adapter_nr);
>  static int digitv_ctrl_msg(struct dvb_usb_device *d,
>   u8 cmd, u8 vv, u8 *wbuf, int wlen, u8 *rbuf, int
> rlen) {
> + struct digitv_state *st = d->priv;
>   int wo = (rbuf == NULL || rlen == 0); /* write-only */
> - u8 sndbuf[7],rcvbuf[7];
> - memset(sndbuf,0,7); memset(rcvbuf,0,7);
>  
> - sndbuf[0] = cmd;
> - sndbuf[1] = vv;
> - sndbuf[2] = wo ? wlen : rlen;
> + memset(st->sndbuf, 0, 7);
> + memset(st->rcvbuf, 0, 7);
> +
> + st->sndbuf[0] = cmd;
> + st->sndbuf[1] = vv;
> + st->sndbuf[2] = wo ? wlen : rlen;
>  
>   if (wo) {
> - memcpy([3],wbuf,wlen);
> - dvb_usb_generic_write(d,sndbuf,7);
> + memcpy(>sndbuf[3], wbuf, wlen);
> + dvb_usb_generic_write(d, st->sndbuf, 7);
>   } else {
> - dvb_usb_generic_rw(d,sndbuf,7,rcvbuf,7,10);
> - memcpy(rbuf,[3],rlen);
> + dvb_usb_generic_rw(d, st->sndbuf, 7, st->rcvbuf, 7,
> 10);
> + memcpy(rbuf, >rcvbuf[3], rlen);
>   }
>   return 0;
>  }
> diff --git a/drivers/media/usb/dvb-usb/digitv.h
> b/drivers/media/usb/dvb-usb/digitv.h index 908c09f4966b..cf104689bdff
> 100644 --- a/drivers/media/usb/dvb-usb/digitv.h
> +++ b/drivers/media/usb/dvb-usb/digitv.h
> @@ -6,6 +6,9 @@
>  
>  struct digitv_state {
>  int is_nxt6000;
> +
> +unsigned char sndbuf[7];
> +unsigned char rcvbuf[7];
>  };
>  
>  /* protocol (from usblogging and the SDK:

Reviewed-By: Patrick Boettcher

Re: [PATCH 14/26] dtt200u: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
0u_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-dtt200u-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -190,6 +207,8 @@ static struct dvb_usb_device_properties
> wt220u_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-02.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -240,6 +259,8 @@ static struct dvb_usb_device_properties
> wt220u_fc_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-fc03.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -290,6 +311,8 @@ static struct dvb_usb_device_properties
> wt220u_zl0353_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-zl0353-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -340,6 +363,8 @@ static struct dvb_usb_device_properties
> wt220u_miglia_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-miglia-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .generic_bulk_ctrl_endpoint = 0x01,
>  

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 14/26] dtt200u: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
v = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -190,6 +207,8 @@ static struct dvb_usb_device_properties
> wt220u_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-02.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -240,6 +259,8 @@ static struct dvb_usb_device_properties
> wt220u_fc_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-fc03.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>       .num_adapters = 1,
>   .adapter = {
>   {
> @@ -290,6 +311,8 @@ static struct dvb_usb_device_properties
> wt220u_zl0353_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-zl0353-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .adapter = {
>   {
> @@ -340,6 +363,8 @@ static struct dvb_usb_device_properties
> wt220u_miglia_properties = { .usb_ctrl = CYPRESS_FX2,
>   .firmware = "dvb-usb-wt220u-miglia-01.fw",
>  
> + .size_of_priv = sizeof(struct dtt200u_state),
> +
>   .num_adapters = 1,
>   .generic_bulk_ctrl_endpoint = 0x01,
>  

Reviewed-By: Patrick Boettcher

Re: [PATCH 19/26] nova-t-usb2: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:29 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/nova-t-usb2.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/nova-t-usb2.c
> b/drivers/media/usb/dvb-usb/nova-t-usb2.c index
> fc7569e2728d..26d7188a1163 100644 ---
> a/drivers/media/usb/dvb-usb/nova-t-usb2.c +++
> b/drivers/media/usb/dvb-usb/nova-t-usb2.c @@ -74,22 +74,29 @@ static
> struct rc_map_table rc_map_haupp_table[] = { */
>  static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int
> *state) {
> - u8 key[5],cmd[2] = { DIBUSB_REQ_POLL_REMOTE, 0x35 },
> data,toggle,custom;
> + u8 *buf, data, toggle, custom;
>   u16 raw;
>   int i;
>   struct dibusb_device_state *st = d->priv;
>  
> - dvb_usb_generic_rw(d,cmd,2,key,5,0);
> + buf = kmalloc(5, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = DIBUSB_REQ_POLL_REMOTE;
> + buf[1] = 0x35;
> + dvb_usb_generic_rw(d, buf, 2, buf, 5, 0);
>  
>   *state = REMOTE_NO_KEY_PRESSED;
> - switch (key[0]) {
> + switch (buf[0]) {
>   case DIBUSB_RC_HAUPPAUGE_KEY_PRESSED:
> - raw = ((key[1] << 8) | key[2]) >> 3;
> + raw = ((buf[1] << 8) | buf[2]) >> 3;
>   toggle = !!(raw & 0x800);
>   data = raw & 0x3f;
>   custom = (raw >> 6) & 0x1f;
>  
> - deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x
> to c: %02x d: %02x toggle:
> %d\n",key[1],key[2],key[3],custom,data,toggle);
> + deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x
> to c: %02x d: %02x toggle: %d\n",
> +buf[1], buf[2], buf[3], custom, data,
> toggle); 
>   for (i = 0; i <
> ARRAY_SIZE(rc_map_haupp_table); i++) { if
> (rc5_data(_map_haupp_table[i]) == data && @@ -117,6 +124,7 @@
> static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int
> *state) break; }
>  
> + kfree(buf);
>   return 0;
>  }
>  

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 19/26] nova-t-usb2: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:29 -0300
Mauro Carvalho Chehab  wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/nova-t-usb2.c | 18 +-
>  1 file changed, 13 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/nova-t-usb2.c
> b/drivers/media/usb/dvb-usb/nova-t-usb2.c index
> fc7569e2728d..26d7188a1163 100644 ---
> a/drivers/media/usb/dvb-usb/nova-t-usb2.c +++
> b/drivers/media/usb/dvb-usb/nova-t-usb2.c @@ -74,22 +74,29 @@ static
> struct rc_map_table rc_map_haupp_table[] = { */
>  static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int
> *state) {
> - u8 key[5],cmd[2] = { DIBUSB_REQ_POLL_REMOTE, 0x35 },
> data,toggle,custom;
> + u8 *buf, data, toggle, custom;
>   u16 raw;
>   int i;
>   struct dibusb_device_state *st = d->priv;
>  
> - dvb_usb_generic_rw(d,cmd,2,key,5,0);
> + buf = kmalloc(5, GFP_KERNEL);
> + if (!buf)
> + return -ENOMEM;
> +
> + buf[0] = DIBUSB_REQ_POLL_REMOTE;
> + buf[1] = 0x35;
> + dvb_usb_generic_rw(d, buf, 2, buf, 5, 0);
>  
>   *state = REMOTE_NO_KEY_PRESSED;
> - switch (key[0]) {
> + switch (buf[0]) {
>   case DIBUSB_RC_HAUPPAUGE_KEY_PRESSED:
> - raw = ((key[1] << 8) | key[2]) >> 3;
> + raw = ((buf[1] << 8) | buf[2]) >> 3;
>   toggle = !!(raw & 0x800);
>   data = raw & 0x3f;
>   custom = (raw >> 6) & 0x1f;
>  
> - deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x
> to c: %02x d: %02x toggle:
> %d\n",key[1],key[2],key[3],custom,data,toggle);
> + deb_rc("raw key code 0x%02x, 0x%02x, 0x%02x
> to c: %02x d: %02x toggle: %d\n",
> +buf[1], buf[2], buf[3], custom, data,
> toggle); 
>   for (i = 0; i <
> ARRAY_SIZE(rc_map_haupp_table); i++) { if
> (rc5_data(_map_haupp_table[i]) == data && @@ -117,6 +124,7 @@
> static int nova_t_rc_query(struct dvb_usb_device *d, u32 *event, int
> *state) break; }
>  
> + kfree(buf);
>   return 0;
>  }
>  

Reviewed-By: Patrick Boettcher

Re: [PATCH 20/26] pctv452e: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
 %02X %02X -> "
> -  "%02X %02X  %02X %02X %02X.",
> + err("I2C error %d; %02X %02X  %02X %02X %02X -> %*ph",
>ret, SYNC_BYTE_OUT, id, addr << 1, snd_len, rcv_len,
> -  buf[0], buf[1], buf[4], buf[5], buf[6]);
> -
> +  7, state->data);
>   return ret;
>  }
>  
> @@ -499,8 +497,7 @@ static u32 pctv452e_i2c_func(struct i2c_adapter
> *adapter) static int pctv452e_power_ctrl(struct dvb_usb_device *d,
> int i) {
>   struct pctv452e_state *state = (struct pctv452e_state
> *)d->priv;
> - u8 b0[] = { 0xaa, 0, PCTV_CMD_RESET, 1, 0 };
> - u8 rx[PCTV_ANSWER_LEN];
> + u8 *rx;
>   int ret;
>  
>   info("%s: %d\n", __func__, i);
> @@ -511,6 +508,10 @@ static int pctv452e_power_ctrl(struct
> dvb_usb_device *d, int i) if (state->initialized)
>   return 0;
>  
> + rx = kmalloc(PCTV_ANSWER_LEN, GFP_KERNEL);
> + if (!rx)
> + return -ENOMEM;
> +
>   /* hmm where shoud this should go? */
>   ret = usb_set_interface(d->udev, 0,
> ISOC_INTERFACE_ALTERNATIVE); if (ret != 0)
> @@ -518,57 +519,62 @@ static int pctv452e_power_ctrl(struct
> dvb_usb_device *d, int i) __func__, ret);
>  
>   /* this is a one-time initialization, dont know where to put
> */
> - b0[1] = state->c++;
> + state->data[0] = 0xaa;
> + state->data[1] = state->c++;
> + state->data[2] = PCTV_CMD_RESET;
> + state->data[3] = 1;
> + state->data[4] = 0;
>   /* reset board */
> - ret = dvb_usb_generic_rw(d, b0, sizeof(b0), rx,
> PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 5, rx,
> PCTV_ANSWER_LEN, 0); if (ret)
> - return ret;
> + goto ret;
>  
> - b0[1] = state->c++;
> - b0[4] = 1;
> + state->data[1] = state->c++;
> + state->data[4] = 1;
>   /* reset board (again?) */
> - ret = dvb_usb_generic_rw(d, b0, sizeof(b0), rx,
> PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 5, rx,
> PCTV_ANSWER_LEN, 0); if (ret)
> - return ret;
> + goto ret;
>  
>   state->initialized = 1;
>  
> - return 0;
> +ret:
> + kfree(rx);
> + return ret;
>  }
>  
>  static int pctv452e_rc_query(struct dvb_usb_device *d)
>  {
>   struct pctv452e_state *state = (struct pctv452e_state
> *)d->priv;
> - u8 b[CMD_BUFFER_SIZE];
> - u8 rx[PCTV_ANSWER_LEN];
>   int ret, i;
>   u8 id = state->c++;
>  
>   /* prepare command header  */
> - b[0] = SYNC_BYTE_OUT;
> - b[1] = id;
> - b[2] = PCTV_CMD_IR;
> - b[3] = 0;
> + state->data[0] = SYNC_BYTE_OUT;
> + state->data[1] = id;
> + state->data[2] = PCTV_CMD_IR;
> + state->data[3] = 0;
>  
>   /* send ir request */
> - ret = dvb_usb_generic_rw(d, b, 4, rx, PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 4,
> +  state->data, PCTV_ANSWER_LEN, 0);
>   if (ret != 0)
>   return ret;
>  
>   if (debug > 3) {
> - info("%s: read: %2d: %*ph: ", __func__, ret, 3, rx);
> - for (i = 0; (i < rx[3]) && ((i+3) <
> PCTV_ANSWER_LEN); i++)
> - info(" %02x", rx[i+3]);
> + info("%s: read: %2d: %*ph: ", __func__, ret, 3,
> state->data);
> + for (i = 0; (i < state->data[3]) && ((i + 3) <
> PCTV_ANSWER_LEN); i++)
> + info(" %02x", state->data[i + 3]);
>  
>   info("\n");
>   }
>  
> - if ((rx[3] == 9) &&  (rx[12] & 0x01)) {
> + if ((state->data[3] == 9) &&  (state->data[12] & 0x01)) {
>   /* got a "press" event */
> - state->last_rc_key = RC_SCANCODE_RC5(rx[7], rx[6]);
> + state->last_rc_key = RC_SCANCODE_RC5(state->data[7],
> state->data[6]); if (debug > 2)
>   info("%s: cmd=0x%02x sys=0x%02x\n",
> - __func__, rx[6], rx[7]);
> + __func__, state->data[6],
> state->data[7]); 
>   rc_keydown(d->rc_dev, RC_TYPE_RC5,
> state->last_rc_key, 0); } else if (state->last_rc_key) {

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 20/26] pctv452e: don't do DMA on stack

2016-10-10 Thread Patrick Boettcher 
X %02X.",
> + err("I2C error %d; %02X %02X  %02X %02X %02X -> %*ph",
>ret, SYNC_BYTE_OUT, id, addr << 1, snd_len, rcv_len,
> -  buf[0], buf[1], buf[4], buf[5], buf[6]);
> -
> +  7, state->data);
>   return ret;
>  }
>  
> @@ -499,8 +497,7 @@ static u32 pctv452e_i2c_func(struct i2c_adapter
> *adapter) static int pctv452e_power_ctrl(struct dvb_usb_device *d,
> int i) {
>   struct pctv452e_state *state = (struct pctv452e_state
> *)d->priv;
> - u8 b0[] = { 0xaa, 0, PCTV_CMD_RESET, 1, 0 };
> - u8 rx[PCTV_ANSWER_LEN];
> + u8 *rx;
>   int ret;
>  
>   info("%s: %d\n", __func__, i);
> @@ -511,6 +508,10 @@ static int pctv452e_power_ctrl(struct
> dvb_usb_device *d, int i) if (state->initialized)
>   return 0;
>  
> + rx = kmalloc(PCTV_ANSWER_LEN, GFP_KERNEL);
> + if (!rx)
> + return -ENOMEM;
> +
>   /* hmm where shoud this should go? */
>   ret = usb_set_interface(d->udev, 0,
> ISOC_INTERFACE_ALTERNATIVE); if (ret != 0)
> @@ -518,57 +519,62 @@ static int pctv452e_power_ctrl(struct
> dvb_usb_device *d, int i) __func__, ret);
>  
>   /* this is a one-time initialization, dont know where to put
> */
> - b0[1] = state->c++;
> + state->data[0] = 0xaa;
> + state->data[1] = state->c++;
> + state->data[2] = PCTV_CMD_RESET;
> + state->data[3] = 1;
> + state->data[4] = 0;
>   /* reset board */
> - ret = dvb_usb_generic_rw(d, b0, sizeof(b0), rx,
> PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 5, rx,
> PCTV_ANSWER_LEN, 0); if (ret)
> - return ret;
> + goto ret;
>  
> - b0[1] = state->c++;
> - b0[4] = 1;
> + state->data[1] = state->c++;
> + state->data[4] = 1;
>   /* reset board (again?) */
> - ret = dvb_usb_generic_rw(d, b0, sizeof(b0), rx,
> PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 5, rx,
> PCTV_ANSWER_LEN, 0); if (ret)
> - return ret;
> + goto ret;
>  
>   state->initialized = 1;
>  
> - return 0;
> +ret:
> + kfree(rx);
> + return ret;
>  }
>  
>  static int pctv452e_rc_query(struct dvb_usb_device *d)
>  {
>   struct pctv452e_state *state = (struct pctv452e_state
> *)d->priv;
> - u8 b[CMD_BUFFER_SIZE];
> - u8 rx[PCTV_ANSWER_LEN];
>   int ret, i;
>   u8 id = state->c++;
>  
>   /* prepare command header  */
> - b[0] = SYNC_BYTE_OUT;
> - b[1] = id;
> - b[2] = PCTV_CMD_IR;
> - b[3] = 0;
> + state->data[0] = SYNC_BYTE_OUT;
> + state->data[1] = id;
> + state->data[2] = PCTV_CMD_IR;
> + state->data[3] = 0;
>  
>   /* send ir request */
> - ret = dvb_usb_generic_rw(d, b, 4, rx, PCTV_ANSWER_LEN, 0);
> + ret = dvb_usb_generic_rw(d, state->data, 4,
> +  state->data, PCTV_ANSWER_LEN, 0);
>   if (ret != 0)
>   return ret;
>  
>   if (debug > 3) {
> - info("%s: read: %2d: %*ph: ", __func__, ret, 3, rx);
> - for (i = 0; (i < rx[3]) && ((i+3) <
> PCTV_ANSWER_LEN); i++)
> - info(" %02x", rx[i+3]);
> + info("%s: read: %2d: %*ph: ", __func__, ret, 3,
> state->data);
> + for (i = 0; (i < state->data[3]) && ((i + 3) <
> PCTV_ANSWER_LEN); i++)
> + info(" %02x", state->data[i + 3]);
>  
>   info("\n");
>   }
>  
> - if ((rx[3] == 9) &&  (rx[12] & 0x01)) {
> + if ((state->data[3] == 9) &&  (state->data[12] & 0x01)) {
>   /* got a "press" event */
> - state->last_rc_key = RC_SCANCODE_RC5(rx[7], rx[6]);
> + state->last_rc_key = RC_SCANCODE_RC5(state->data[7],
> state->data[6]); if (debug > 2)
>   info("%s: cmd=0x%02x sys=0x%02x\n",
> - __func__, rx[6], rx[7]);
> + __func__, state->data[6],
> state->data[7]); 
>   rc_keydown(d->rc_dev, RC_TYPE_RC5,
> state->last_rc_key, 0); } else if (state->last_rc_key) {

Reviewed-By: Patrick Boettcher

Re: [PATCH 22/26] technisat-usb2: use DMA buffers for I2C transfers

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:32 -0300
Mauro Carvalho Chehab <mche...@s-opensource.com> wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> On this driver, most of the transfers are OK, but the I2C
> one was using stack.
> 
> Signed-off-by: Mauro Carvalho Chehab <mche...@s-opensource.com>
> ---
>  drivers/media/usb/dvb-usb/technisat-usb2.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
> b/drivers/media/usb/dvb-usb/technisat-usb2.c index
> d9f3262bf071..4706628a3ed5 100644 ---
> a/drivers/media/usb/dvb-usb/technisat-usb2.c +++
> b/drivers/media/usb/dvb-usb/technisat-usb2.c @@ -89,9 +89,13 @@
> struct technisat_usb2_state { static int
> technisat_usb2_i2c_access(struct usb_device *udev, u8 device_addr, u8
> *tx, u8 txlen, u8 *rx, u8 rxlen) {
> - u8 b[64];
> + u8 *b;
>   int ret, actual_length;
>  
> + b = kmalloc(64, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
> +
>   deb_i2c("i2c-access: %02x, tx: ", device_addr);
>   debug_dump(tx, txlen, deb_i2c);
>   deb_i2c(" ");
> @@ -123,7 +127,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, 
>   if (ret < 0) {
>   err("i2c-error: out failed %02x = %d", device_addr,
> ret);
> - return -ENODEV;
> + goto err;
>   }
>  
>   ret = usb_bulk_msg(udev,
> @@ -131,7 +135,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, b, 64, _length, 1000);
>   if (ret < 0) {
>   err("i2c-error: in failed %02x = %d", device_addr,
> ret);
> - return -ENODEV;
> + goto err;
>   }
>  
>   if (b[0] != I2C_STATUS_OK) {
> @@ -140,7 +144,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, if (!(b[0] == I2C_STATUS_NAK &&
>   device_addr == 0x60
>   /* && device_is_technisat_usb2 */))
> - return -ENODEV;
> + goto err;
>   }
>  
>   deb_i2c("status: %d, ", b[0]);
> @@ -154,7 +158,9 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, 
>   deb_i2c("\n");
>  
> - return 0;
> +err:
> + kfree(b);
> + return ret;
>  }
>  
>  static int technisat_usb2_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg *msg,

Reviewed-By: Patrick Boettcher <patrick.boettc...@posteo.de>

Re: [PATCH 22/26] technisat-usb2: use DMA buffers for I2C transfers

2016-10-10 Thread Patrick Boettcher 
On Fri,  7 Oct 2016 14:24:32 -0300
Mauro Carvalho Chehab  wrote:

> The USB control messages require DMA to work. We cannot pass
> a stack-allocated buffer, as it is not warranted that the
> stack would be into a DMA enabled area.
> 
> On this driver, most of the transfers are OK, but the I2C
> one was using stack.
> 
> Signed-off-by: Mauro Carvalho Chehab 
> ---
>  drivers/media/usb/dvb-usb/technisat-usb2.c | 16 +++-
>  1 file changed, 11 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
> b/drivers/media/usb/dvb-usb/technisat-usb2.c index
> d9f3262bf071..4706628a3ed5 100644 ---
> a/drivers/media/usb/dvb-usb/technisat-usb2.c +++
> b/drivers/media/usb/dvb-usb/technisat-usb2.c @@ -89,9 +89,13 @@
> struct technisat_usb2_state { static int
> technisat_usb2_i2c_access(struct usb_device *udev, u8 device_addr, u8
> *tx, u8 txlen, u8 *rx, u8 rxlen) {
> - u8 b[64];
> + u8 *b;
>   int ret, actual_length;
>  
> + b = kmalloc(64, GFP_KERNEL);
> + if (!b)
> + return -ENOMEM;
> +
>   deb_i2c("i2c-access: %02x, tx: ", device_addr);
>   debug_dump(tx, txlen, deb_i2c);
>   deb_i2c(" ");
> @@ -123,7 +127,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, 
>   if (ret < 0) {
>   err("i2c-error: out failed %02x = %d", device_addr,
> ret);
> - return -ENODEV;
> + goto err;
>   }
>  
>   ret = usb_bulk_msg(udev,
> @@ -131,7 +135,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, b, 64, _length, 1000);
>   if (ret < 0) {
>   err("i2c-error: in failed %02x = %d", device_addr,
> ret);
> - return -ENODEV;
> + goto err;
>   }
>  
>   if (b[0] != I2C_STATUS_OK) {
> @@ -140,7 +144,7 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, if (!(b[0] == I2C_STATUS_NAK &&
>   device_addr == 0x60
>   /* && device_is_technisat_usb2 */))
> - return -ENODEV;
> + goto err;
>   }
>  
>   deb_i2c("status: %d, ", b[0]);
> @@ -154,7 +158,9 @@ static int technisat_usb2_i2c_access(struct
> usb_device *udev, 
>   deb_i2c("\n");
>  
> - return 0;
> +err:
> + kfree(b);
> + return ret;
>  }
>  
>  static int technisat_usb2_i2c_xfer(struct i2c_adapter *adap, struct
> i2c_msg *msg,

Reviewed-By: Patrick Boettcher

Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

2016-10-10 Thread Patrick Boettcher 
Hi, der Herr Hofrat ;-)

On Sat, 8 Oct 2016 13:57:14 +
Nicholas Mc Guire  wrote:
> - lo6 |= (1 << 2) | 2;
> - else
> - lo6 |= (1 << 2) | 1;
> + lo6 |= (1 << 2) | 2;//SigmaDelta and Dither
> + else {
> + if (state->identity.in_soc)
> + lo6 |= (1 << 2) | 2;//SigmaDelta and
> Dither
> + else
> + lo6 |= (1 << 2) | 2;//SigmaDelta and
> Dither
> + }
> 
>  resulting in the current code-base of:
> 
>if (Rest > 0) {
>if (state->config->analog_output)
>lo6 |= (1 << 2) | 2;
>else {
>if (state->identity.in_soc)
>lo6 |= (1 << 2) | 2;
>else
>lo6 |= (1 << 2) | 2;
>}
>Den = 255;
>}
> 
>  The problem now is that the if and the else(if/else) are
>  all the same and thus the conditions have no effect. Further
>  the origninal code actually had different if/else - so I 
>  wonder if this is a cut bug here ?

I may answer on behalf of Olivier (didn't his address bounce?).

I don't remember the details, this patch must date from 2011 or
before, but at that time we generated the linux-driver from our/their
internal sources.

Updates in this area were achieved by a lot of thinking + a mix of trial
and error (after hours/days/weeks of RF hardware validation). 

This logic above has 3 possibilities: 

  - we use the analog-output, or 
  - we are using the digital one, then there is whether we are being in
a SoC or not (SIP or sinlge chip).

At some point in time all values have been different. In the end, they
aren't anymore, but in case someone wants to try a different value,
there are placeholders in the code to easily inject these values.

Now the device is stable, maybe even obsolete. We could remove all the
branches resulting in the same value for lo6.

--
Patrick.

Re: RFC - unclear change in "[media] DiBxxxx: Codingstype updates"

2016-10-10 Thread Patrick Boettcher 
Hi, der Herr Hofrat ;-)

On Sat, 8 Oct 2016 13:57:14 +
Nicholas Mc Guire  wrote:
> - lo6 |= (1 << 2) | 2;
> - else
> - lo6 |= (1 << 2) | 1;
> + lo6 |= (1 << 2) | 2;//SigmaDelta and Dither
> + else {
> + if (state->identity.in_soc)
> + lo6 |= (1 << 2) | 2;//SigmaDelta and
> Dither
> + else
> + lo6 |= (1 << 2) | 2;//SigmaDelta and
> Dither
> + }
> 
>  resulting in the current code-base of:
> 
>if (Rest > 0) {
>if (state->config->analog_output)
>lo6 |= (1 << 2) | 2;
>else {
>if (state->identity.in_soc)
>lo6 |= (1 << 2) | 2;
>else
>lo6 |= (1 << 2) | 2;
>}
>Den = 255;
>}
> 
>  The problem now is that the if and the else(if/else) are
>  all the same and thus the conditions have no effect. Further
>  the origninal code actually had different if/else - so I 
>  wonder if this is a cut bug here ?

I may answer on behalf of Olivier (didn't his address bounce?).

I don't remember the details, this patch must date from 2011 or
before, but at that time we generated the linux-driver from our/their
internal sources.

Updates in this area were achieved by a lot of thinking + a mix of trial
and error (after hours/days/weeks of RF hardware validation). 

This logic above has 3 possibilities: 

  - we use the analog-output, or 
  - we are using the digital one, then there is whether we are being in
a SoC or not (SIP or sinlge chip).

At some point in time all values have been different. In the end, they
aren't anymore, but in case someone wants to try a different value,
there are placeholders in the code to easily inject these values.

Now the device is stable, maybe even obsolete. We could remove all the
branches resulting in the same value for lo6.

--
Patrick.

dvb-usb stack-memory used for URB-buffers (was: Re: Problem with VMAP_STACK=y)

2016-10-05 Thread Patrick Boettcher 
Hi,

On Tue, 4 Oct 2016 15:26:28 +0200 (CEST)
Jiri Kosina  wrote:

> On Tue, 4 Oct 2016, Jörg Otte wrote:
> 
> > With kernel 4.8.0-01558-g21f54dd I get thousands of
> > "dvb-usb: bulk message failed: -11 (1/0)"
> > messages in the logs and the DVB adapter is not working.
> > 
> > It tourned out the new config option VMAP_STACK=y (which is the
> > default) is the culprit.
> > No problems for me with VMAP_STACK=n.  
> 
> I'd guess that this is EAGAIN coming from usb_hcd_map_urb_for_dma()
> as the DVB driver is trying to perform on-stack DMA.

I really thought that this youngster-mistake of mien (these
drivers+framework date from 2004-2006 and there it worked just fine)
had been fixed some years ago. 

Seems not the be the case :-(.

However, I'm happy to see people using these devices now. Even
though I don't have them anymore (or never had them in the first place).

Mauro, could you please bring me up to speed or remind when and
where you did changes in this regard? I got a little bit rusty
regarding linux-media, but I'd be happy to help.

regards,
-- 
Patrick.

dvb-usb stack-memory used for URB-buffers (was: Re: Problem with VMAP_STACK=y)

2016-10-05 Thread Patrick Boettcher 
Hi,

On Tue, 4 Oct 2016 15:26:28 +0200 (CEST)
Jiri Kosina  wrote:

> On Tue, 4 Oct 2016, Jörg Otte wrote:
> 
> > With kernel 4.8.0-01558-g21f54dd I get thousands of
> > "dvb-usb: bulk message failed: -11 (1/0)"
> > messages in the logs and the DVB adapter is not working.
> > 
> > It tourned out the new config option VMAP_STACK=y (which is the
> > default) is the culprit.
> > No problems for me with VMAP_STACK=n.  
> 
> I'd guess that this is EAGAIN coming from usb_hcd_map_urb_for_dma()
> as the DVB driver is trying to perform on-stack DMA.

I really thought that this youngster-mistake of mien (these
drivers+framework date from 2004-2006 and there it worked just fine)
had been fixed some years ago. 

Seems not the be the case :-(.

However, I'm happy to see people using these devices now. Even
though I don't have them anymore (or never had them in the first place).

Mauro, could you please bring me up to speed or remind when and
where you did changes in this regard? I got a little bit rusty
regarding linux-media, but I'd be happy to help.

regards,
-- 
Patrick.

Re: Problem with VMAP_STACK=y

2016-10-05 Thread Patrick Boettcher 
On Wed, 5 Oct 2016 09:26:29 +0200 (CEST)
Jiri Kosina  wrote:

> On Tue, 4 Oct 2016, Jörg Otte wrote:
> 
> > Thanks for the quick response.
> > Drivers are:
> > dvb_core, dvb_usb, dbv_usb_cynergyT2  
> 
> This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
> to be able to find it, and the only google hit I am getting is your
> very mail to LKML :)

It's a typo, it should say dvb_usb_cinergyT2.

-- 
Patrick.

Re: Problem with VMAP_STACK=y

2016-10-05 Thread Patrick Boettcher 
On Wed, 5 Oct 2016 09:26:29 +0200 (CEST)
Jiri Kosina  wrote:

> On Tue, 4 Oct 2016, Jörg Otte wrote:
> 
> > Thanks for the quick response.
> > Drivers are:
> > dvb_core, dvb_usb, dbv_usb_cynergyT2  
> 
> This dbv_usb_cynergyT2 is not from Linus' tree, is it? I don't seem
> to be able to find it, and the only google hit I am getting is your
> very mail to LKML :)

It's a typo, it should say dvb_usb_cinergyT2.

-- 
Patrick.

Re: Kernel docs: muddying the waters a bit

2016-02-18 Thread Patrick Boettcher 
On Thu, 18 Feb 2016 10:44:34 -0200
Mauro Carvalho Chehab  wrote:
> > > It is workable, but I guess nested tables produced a better
> > > result.
> > > 
> > > I did myself a test with nested tables with asciidoc too:
> > > 
> > > https://mchehab.fedorapeople.org/media-kabi-docs-test/pandoc_asciidoc/table.html
> > > https://mchehab.fedorapeople.org/media-kabi-docs-test/pandoc_asciidoc/table.ascii
> > > 
> > > With looks very decent to me.
> > 
> > It does, except for the vertical alignment of the third column (at
> > least when viewed with google chrome).  
> 
> Not sure what you mean. Here, it looks fine on both Firefox and
> Chrome, except that the second colum size could be smaller. If this
> is what you're meaning this can be fixed by changing the second line
> from:

I think Hans' problem (I see it as well) is coming from css-style of
"paragraph" which is:

margin-top: 0.5em;
margin-bottom: 0.5em;

This makes the third column non-vertical-aligned

--
Patrick

Re: Kernel docs: muddying the waters a bit

2016-02-18 Thread Patrick Boettcher 
On Thu, 18 Feb 2016 10:44:34 -0200
Mauro Carvalho Chehab  wrote:
> > > It is workable, but I guess nested tables produced a better
> > > result.
> > > 
> > > I did myself a test with nested tables with asciidoc too:
> > > 
> > > https://mchehab.fedorapeople.org/media-kabi-docs-test/pandoc_asciidoc/table.html
> > > https://mchehab.fedorapeople.org/media-kabi-docs-test/pandoc_asciidoc/table.ascii
> > > 
> > > With looks very decent to me.
> > 
> > It does, except for the vertical alignment of the third column (at
> > least when viewed with google chrome).  
> 
> Not sure what you mean. Here, it looks fine on both Firefox and
> Chrome, except that the second colum size could be smaller. If this
> is what you're meaning this can be fixed by changing the second line
> from:

I think Hans' problem (I see it as well) is coming from css-style of
"paragraph" which is:

margin-top: 0.5em;
margin-bottom: 0.5em;

This makes the third column non-vertical-aligned

--
Patrick

csdio-kernel module status, if any (was: Re: char interface to sdio, chdio.c)

2015-11-03 Thread Patrick Boettcher 
Hi all,

Sorry for posting out-of-thread, but I don't have the original mail and
thus cannot reply.

If refer to this thread:

https://lkml.org/lkml/2014/7/15/975

where you guys started to review and prepare things for
upstream-inclusion of the csdio-module. 

Strangely enough the last mail on lkml.org isn't showing - I had to
use another lkml-archive: 
http://lkml.iu.edu/hypermail/linux/kernel/1407.2/01971.html

In it, greg is saying, that this thing is "_way_ down" on his list. 

Has, by magic, anything evolved regarding the remarks made by Arnd and
I'm just too blind to find it? (nothing in recent kernel sources)

We are having the exact same need (a basic sdio-device-driver
accessing things from user-space) and are ready to invest some time in
it (if nothing comes in between) - but of course would like to start
from something sane.

best regards
--
Patrick.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

csdio-kernel module status, if any (was: Re: char interface to sdio, chdio.c)

2015-11-03 Thread Patrick Boettcher 
Hi all,

Sorry for posting out-of-thread, but I don't have the original mail and
thus cannot reply.

If refer to this thread:

https://lkml.org/lkml/2014/7/15/975

where you guys started to review and prepare things for
upstream-inclusion of the csdio-module. 

Strangely enough the last mail on lkml.org isn't showing - I had to
use another lkml-archive: 
http://lkml.iu.edu/hypermail/linux/kernel/1407.2/01971.html

In it, greg is saying, that this thing is "_way_ down" on his list. 

Has, by magic, anything evolved regarding the remarks made by Arnd and
I'm just too blind to find it? (nothing in recent kernel sources)

We are having the exact same need (a basic sdio-device-driver
accessing things from user-space) and are ready to invest some time in
it (if nothing comes in between) - but of course would like to start
from something sane.

best regards
--
Patrick.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: android: fix coding style error (v2)

2015-01-14 Thread Patrick Boettcher 
Hi Dan,

Thanks for your valuable input. It's appreciated.

On Wed, 14 Jan 2015 12:28:44 +0300 Dan Carpenter
 wrote:
> > lots of Cc:'s [..]
> 
> This block is not needed.  This is a whitespace patch not something
> controversial where we will need to look at who was CC'd so that we
> can get annoyed at them for ignoring critical information.

Yes, I was wondering which criteria to apply for stripping off people
from the get_maintainer.pl-output - and that even though my patch is
brilliant ;-). 

Thanks again,
--
Patrick.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: fix coding style error (v2)

2015-01-14 Thread Patrick Boettcher 
Simple style fix - 80 char limit was exceeded.

This is second version of the patch. Thanks Joe Perches.

Context: eudyptula challenge (http://eudyptula-challenge.org/)

Signed-off-by: Patrick Boettcher 

Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: John Stultz 
Cc: Peter Senna Tschudin 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Tapasweni Pathak 
Cc: Joe Perches 
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/android/sync_debug.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 1532a86..d6edf37 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -96,8 +96,9 @@ static void sync_print_pt(struct seq_file *s, struct sync_pt 
*pt, bool fence)
   sync_status_str(status));
 
if (status <= 0) {
-   struct timespec64 ts64 = 
ktime_to_timespec64(pt->base.timestamp);
+   struct timespec64 ts64;
 
+   ts64 = ktime_to_timespec64(pt->base.timestamp);
seq_printf(s, "@%lld.%09ld", (s64)ts64.tv_sec, ts64.tv_nsec);
}
 
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: fix coding style error

2015-01-14 Thread Patrick Boettcher 
Simple style fix - 80 char limit was exceeded.

Context: eudyptula challenge (http://eudyptula-challenge.org/)

Signed-off-by: Patrick Boettcher 

Cc: Greg Kroah-Hartman 
Cc: Arnd Bergmann 
Cc: John Stultz 
Cc: Peter Senna Tschudin 
Cc: Daniel Vetter 
Cc: Maarten Lankhorst 
Cc: Tapasweni Pathak 
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman 
---
 drivers/staging/android/sync_debug.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 1532a86..9a2aaf8 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -96,7 +96,8 @@ static void sync_print_pt(struct seq_file *s, struct sync_pt 
*pt, bool fence)
   sync_status_str(status));
 
if (status <= 0) {
-   struct timespec64 ts64 = 
ktime_to_timespec64(pt->base.timestamp);
+   struct timespec64 ts64 =
+   ktime_to_timespec64(pt->base.timestamp);
 
seq_printf(s, "@%lld.%09ld", (s64)ts64.tv_sec, ts64.tv_nsec);
}
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: fix coding style error

2015-01-14 Thread Patrick Boettcher 
Simple style fix - 80 char limit was exceeded.

Context: eudyptula challenge (http://eudyptula-challenge.org/)

Signed-off-by: Patrick Boettcher patrick.boettc...@posteo.de

Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Arnd Bergmann a...@arndb.de
Cc: John Stultz john.stu...@linaro.org
Cc: Peter Senna Tschudin peter.se...@gmail.com
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: Tapasweni Pathak tapaswenipat...@gmail.com
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
---
 drivers/staging/android/sync_debug.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 1532a86..9a2aaf8 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -96,7 +96,8 @@ static void sync_print_pt(struct seq_file *s, struct sync_pt 
*pt, bool fence)
   sync_status_str(status));
 
if (status = 0) {
-   struct timespec64 ts64 = 
ktime_to_timespec64(pt-base.timestamp);
+   struct timespec64 ts64 =
+   ktime_to_timespec64(pt-base.timestamp);
 
seq_printf(s, @%lld.%09ld, (s64)ts64.tv_sec, ts64.tv_nsec);
}
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] staging: android: fix coding style error (v2)

2015-01-14 Thread Patrick Boettcher 
Simple style fix - 80 char limit was exceeded.

This is second version of the patch. Thanks Joe Perches.

Context: eudyptula challenge (http://eudyptula-challenge.org/)

Signed-off-by: Patrick Boettcher patrick.boettc...@posteo.de

Cc: Greg Kroah-Hartman gre...@linuxfoundation.org
Cc: Arnd Bergmann a...@arndb.de
Cc: John Stultz john.stu...@linaro.org
Cc: Peter Senna Tschudin peter.se...@gmail.com
Cc: Daniel Vetter dan...@ffwll.ch
Cc: Maarten Lankhorst maarten.lankho...@canonical.com
Cc: Tapasweni Pathak tapaswenipat...@gmail.com
Cc: Joe Perches j...@perches.com
Cc: de...@driverdev.osuosl.org
Cc: linux-kernel@vger.kernel.org
---
 drivers/staging/android/sync_debug.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/staging/android/sync_debug.c 
b/drivers/staging/android/sync_debug.c
index 1532a86..d6edf37 100644
--- a/drivers/staging/android/sync_debug.c
+++ b/drivers/staging/android/sync_debug.c
@@ -96,8 +96,9 @@ static void sync_print_pt(struct seq_file *s, struct sync_pt 
*pt, bool fence)
   sync_status_str(status));
 
if (status = 0) {
-   struct timespec64 ts64 = 
ktime_to_timespec64(pt-base.timestamp);
+   struct timespec64 ts64;
 
+   ts64 = ktime_to_timespec64(pt-base.timestamp);
seq_printf(s, @%lld.%09ld, (s64)ts64.tv_sec, ts64.tv_nsec);
}
 
-- 
2.1.4

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] staging: android: fix coding style error (v2)

2015-01-14 Thread Patrick Boettcher 
Hi Dan,

Thanks for your valuable input. It's appreciated.

On Wed, 14 Jan 2015 12:28:44 +0300 Dan Carpenter
dan.carpen...@oracle.com wrote:
  lots of Cc:'s [..]
 
 This block is not needed.  This is a whitespace patch not something
 controversial where we will need to look at who was CC'd so that we
 can get annoyed at them for ignoring critical information.

Yes, I was wondering which criteria to apply for stripping off people
from the get_maintainer.pl-output - and that even though my patch is
brilliant ;-). 

Thanks again,
--
Patrick.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dvb-usb/technisat-usb2: Fix cut-n-paste thinko

2013-09-05 Thread Patrick Boettcher 
Hi Dave,

On Wednesday 04 September 2013 19:59:17 Dave Jones wrote:
> This looks like it was cut and pasted from the code above which does
> similar checks on txlen, but someone forgot to change the variable.

This someone would be me.

> Signed-off-by: Dave Jones 
> 
> diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
> b/drivers/media/usb/dvb-usb/technisat-usb2.c index 40832a1..98d24ae
> 100644
> --- a/drivers/media/usb/dvb-usb/technisat-usb2.c
> +++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
> @@ -102,7 +102,7 @@ static int technisat_usb2_i2c_access(struct usb_device
> *udev, if (rxlen > 62) {
>   err("i2c RX buffer can't exceed 62 bytes (dev 0x%02x)",
>   device_addr);
> - txlen = 62;
> + rxlen = 62;
>   }
> 
>   b[0] = I2C_SPEED_100KHZ_BIT;

Nice catch.

Mauro, feel free to add my signed-off-line, when integrating

Signed-off-by: Patrick Boettcher 



--
Patrick 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dvb-usb/technisat-usb2: Fix cut-n-paste thinko

2013-09-05 Thread Patrick Boettcher 
Hi Dave,

On Wednesday 04 September 2013 19:59:17 Dave Jones wrote:
 This looks like it was cut and pasted from the code above which does
 similar checks on txlen, but someone forgot to change the variable.

This someone would be me.

 Signed-off-by: Dave Jones da...@fedoraproject.org
 
 diff --git a/drivers/media/usb/dvb-usb/technisat-usb2.c
 b/drivers/media/usb/dvb-usb/technisat-usb2.c index 40832a1..98d24ae
 100644
 --- a/drivers/media/usb/dvb-usb/technisat-usb2.c
 +++ b/drivers/media/usb/dvb-usb/technisat-usb2.c
 @@ -102,7 +102,7 @@ static int technisat_usb2_i2c_access(struct usb_device
 *udev, if (rxlen  62) {
   err(i2c RX buffer can't exceed 62 bytes (dev 0x%02x),
   device_addr);
 - txlen = 62;
 + rxlen = 62;
   }
 
   b[0] = I2C_SPEED_100KHZ_BIT;

Nice catch.

Mauro, feel free to add my signed-off-line, when integrating

Signed-off-by: Patrick Boettcher pboettc...@kernellabs.com



--
Patrick 
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dib7000m_i2c_enumeration() is unused

2007-11-10 Thread Patrick Boettcher 
Hi all,

This is another story of "the chip-vendor provides driver support and is 
waiting for device to hit the market". 

DiBcom knows that there are devices out there that are using the dib7000m 
in way that they need the dib7000m_i2c_enumeration to work properly. But 
it is impossible to know the devices in advance. This function is there 
for the case a user or developper needs it to add support for his board.

Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/




On Mon, 5 Nov 2007, Adrian Bunk wrote:

> dib7000m_i2c_enumeration() is currently unused, but although I don't 
> understand the code I have a gut feeling it should have been used in 
> dib0700_devices.c. Is this correct?
> 
> cu
> Adrian
> 
> -- 
> 
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: dib7000m_i2c_enumeration() is unused

2007-11-10 Thread Patrick Boettcher 
Hi all,

This is another story of the chip-vendor provides driver support and is 
waiting for device to hit the market. 

DiBcom knows that there are devices out there that are using the dib7000m 
in way that they need the dib7000m_i2c_enumeration to work properly. But 
it is impossible to know the devices in advance. This function is there 
for the case a user or developper needs it to add support for his board.

Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/




On Mon, 5 Nov 2007, Adrian Bunk wrote:

 dib7000m_i2c_enumeration() is currently unused, but although I don't 
 understand the code I have a gut feeling it should have been used in 
 dib0700_devices.c. Is this correct?
 
 cu
 Adrian
 
 -- 
 
Is there not promise of rain? Ling Tan asked suddenly out
 of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v4l-dvb-maintainer] DVB: BANDWIDTH_TO_KHZ strangeness

2007-10-22 Thread Patrick Boettcher 
Hi all,

This coverity checker is great. He even finds all the things which are 
there because I'm lazy ;) .

The dib-drivers are all generated from our internal drivers to have at 
least something for Linux. Because of no time there is no dedicated 
source for the kernel but just the processed one.

The particular issue here is, that the internal architecture supports a 
variable bandwidth while the linux-dvb architecture only has 3 fixed 
values. 

I know that in the future the linux-dvb-API will also support other 
bandwidths so I'm begging for mercy for those 3 things here to not get too 
much out-of-sync with our internal code.

thanks,
Patrick.

On Sun, 14 Oct 2007, Adrian Bunk wrote:
> drivers/media/dvb/frontends/dibx000_common.h contains:
> 
> <--  snip  -->
> 
> ...
> #define BANDWIDTH_TO_KHZ(v) ( (v) == BANDWIDTH_8_MHZ  ? 8000 : \
>  (v) == BANDWIDTH_7_MHZ  ? 7000 : \
>  (v) == BANDWIDTH_6_MHZ  ? 6000 : 8000 )
> ...
> 
> <--  snip  -->
> 
> 
> Commit b6884a17fc70e979ef34e4b5560988b522bb50a0 added to both of 
> drivers/media/dvb/frontends/dib7000{m,p}.c:
> 
> <--  snip  -->
> 
> ...
> factor = BANDWIDTH_TO_KHZ(ch->u.ofdm.bandwidth);
> if (factor >= 5000)
> factor = 1;
> else
> factor = 6;
> ...
> 
> <--  snip  -->
> 
> 
> factor < 5000 is obviously never possible.
> 
> drivers/media/dvb/frontends/dib0070.c contains a similar assumption that 
> BANDWIDTH_TO_KHZ() could result in values other than {6,7,8}000
> (I haven't checked whether there are more such assumptions in other 
> places).
> 
> Spotted by the Coverity checker.
> 
> 
> cu
> Adrian
> 
> -- 
> 
>"Is there not promise of rain?" Ling Tan asked suddenly out
> of the darkness. There had been need of rain for many days.
>"Only a promise," Lao Er said.
>Pearl S. Buck - Dragon Seed
> 
> 
> ___
> v4l-dvb-maintainer mailing list
> [EMAIL PROTECTED]
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
> 

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [v4l-dvb-maintainer] DVB: BANDWIDTH_TO_KHZ strangeness

2007-10-22 Thread Patrick Boettcher 
Hi all,

This coverity checker is great. He even finds all the things which are 
there because I'm lazy ;) .

The dib-drivers are all generated from our internal drivers to have at 
least something for Linux. Because of no time there is no dedicated 
source for the kernel but just the processed one.

The particular issue here is, that the internal architecture supports a 
variable bandwidth while the linux-dvb architecture only has 3 fixed 
values. 

I know that in the future the linux-dvb-API will also support other 
bandwidths so I'm begging for mercy for those 3 things here to not get too 
much out-of-sync with our internal code.

thanks,
Patrick.

On Sun, 14 Oct 2007, Adrian Bunk wrote:
 drivers/media/dvb/frontends/dibx000_common.h contains:
 
 --  snip  --
 
 ...
 #define BANDWIDTH_TO_KHZ(v) ( (v) == BANDWIDTH_8_MHZ  ? 8000 : \
  (v) == BANDWIDTH_7_MHZ  ? 7000 : \
  (v) == BANDWIDTH_6_MHZ  ? 6000 : 8000 )
 ...
 
 --  snip  --
 
 
 Commit b6884a17fc70e979ef34e4b5560988b522bb50a0 added to both of 
 drivers/media/dvb/frontends/dib7000{m,p}.c:
 
 --  snip  --
 
 ...
 factor = BANDWIDTH_TO_KHZ(ch-u.ofdm.bandwidth);
 if (factor = 5000)
 factor = 1;
 else
 factor = 6;
 ...
 
 --  snip  --
 
 
 factor  5000 is obviously never possible.
 
 drivers/media/dvb/frontends/dib0070.c contains a similar assumption that 
 BANDWIDTH_TO_KHZ() could result in values other than {6,7,8}000
 (I haven't checked whether there are more such assumptions in other 
 places).
 
 Spotted by the Coverity checker.
 
 
 cu
 Adrian
 
 -- 
 
Is there not promise of rain? Ling Tan asked suddenly out
 of the darkness. There had been need of rain for many days.
Only a promise, Lao Er said.
Pearl S. Buck - Dragon Seed
 
 
 ___
 v4l-dvb-maintainer mailing list
 [EMAIL PROTECTED]
 http://www.linuxtv.org/cgi-bin/mailman/listinfo/v4l-dvb-maintainer
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fix for race problem in DVB USB drivers (dibusb)

2005-08-27 Thread Patrick Boettcher 

Hi Linus,

Below you'll find a patch, which fixes an ugly problem with some DVB USB 
devices. I would highly appreciate the inclusion into the linux kernel 
before 2.6.13 is released.


Thank you very much in advance,
Patrick.



Fixed race between submitting streaming URBs in the driver and starting 
the actual transfer in hardware (demodulator and USB controller) which 
sometimes lead to garbled data transfers. URBs are now submitted first, 
then the transfer is enabled. Dibusb devices and clones are now fully 
functional again.


Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]>

Index: linux/drivers/media/dvb/dvb-usb/dibusb-common.c
===
RCS file: 
/cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/dvb-usb/dibusb-common.c,v
retrieving revision 1.9
diff -u -r1.9 dibusb-common.c
--- linux/drivers/media/dvb/dvb-usb/dibusb-common.c 19 Jun 2005 13:13:47 
-  1.9
+++ linux/drivers/media/dvb/dvb-usb/dibusb-common.c 27 Aug 2005 16:56:10 
-
@@ -69,13 +69,22 @@

 int dibusb2_0_streaming_ctrl(struct dvb_usb_device *d, int onoff)
 {
-   u8 b[2];
-   b[0] = DIBUSB_REQ_SET_IOCTL;
-   b[1] = onoff ? DIBUSB_IOCTL_CMD_ENABLE_STREAM : 
DIBUSB_IOCTL_CMD_DISABLE_STREAM;
+   u8 b[3] = { 0 };
+   int ret;

-   dvb_usb_generic_write(d,b,3);
+   if ((ret = dibusb_streaming_ctrl(d,onoff)) < 0)
+   return ret;

-   return dibusb_streaming_ctrl(d,onoff);
+   if (onoff) {
+   b[0] = DIBUSB_REQ_SET_STREAMING_MODE;
+   b[1] = 0x00;
+   if ((ret = dvb_usb_generic_write(d,b,2)) < 0)
+   return ret;
+   }
+
+   b[0] = DIBUSB_REQ_SET_IOCTL;
+   b[1] = onoff ? DIBUSB_IOCTL_CMD_ENABLE_STREAM : 
DIBUSB_IOCTL_CMD_DISABLE_STREAM;
+   return dvb_usb_generic_write(d,b,3);
 }
 EXPORT_SYMBOL(dibusb2_0_streaming_ctrl);

Index: linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
===
RCS file: 
/cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c,v
retrieving revision 1.8
diff -u -r1.8 dvb-usb-dvb.c
--- linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c   2 Jul 2005 12:49:23 
-   1.8
+++ linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c   27 Aug 2005 16:56:10 
-
@@ -23,12 +23,12 @@
 */
if (newfeedcount == 0) {
deb_ts("stop feeding\n");
+   dvb_usb_urb_kill(d);

if (d->props.streaming_ctrl != NULL)
if ((ret = d->props.streaming_ctrl(d,0)))
err("error while stopping stream.");

-   dvb_usb_urb_kill(d);
}

d->feedcount = newfeedcount;
@@ -44,6 +44,8 @@
 * for reception.
 */
if (d->feedcount == onoff && d->feedcount > 0) {
+   deb_ts("submitting all URBs\n");
+   dvb_usb_urb_submit(d);

deb_ts("controlling pid parser\n");
if (d->props.caps & DVB_USB_HAS_PID_FILTER &&
@@ -59,7 +61,6 @@
return -ENODEV;
}

-   dvb_usb_urb_submit(d);
}
return 0;
 }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] fix for race problem in DVB USB drivers (dibusb)

2005-08-27 Thread Patrick Boettcher 

Hi Linus,

Below you'll find a patch, which fixes an ugly problem with some DVB USB 
devices. I would highly appreciate the inclusion into the linux kernel 
before 2.6.13 is released.


Thank you very much in advance,
Patrick.



Fixed race between submitting streaming URBs in the driver and starting 
the actual transfer in hardware (demodulator and USB controller) which 
sometimes lead to garbled data transfers. URBs are now submitted first, 
then the transfer is enabled. Dibusb devices and clones are now fully 
functional again.


Signed-off-by: Patrick Boettcher [EMAIL PROTECTED]

Index: linux/drivers/media/dvb/dvb-usb/dibusb-common.c
===
RCS file: 
/cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/dvb-usb/dibusb-common.c,v
retrieving revision 1.9
diff -u -r1.9 dibusb-common.c
--- linux/drivers/media/dvb/dvb-usb/dibusb-common.c 19 Jun 2005 13:13:47 
-  1.9
+++ linux/drivers/media/dvb/dvb-usb/dibusb-common.c 27 Aug 2005 16:56:10 
-
@@ -69,13 +69,22 @@

 int dibusb2_0_streaming_ctrl(struct dvb_usb_device *d, int onoff)
 {
-   u8 b[2];
-   b[0] = DIBUSB_REQ_SET_IOCTL;
-   b[1] = onoff ? DIBUSB_IOCTL_CMD_ENABLE_STREAM : 
DIBUSB_IOCTL_CMD_DISABLE_STREAM;
+   u8 b[3] = { 0 };
+   int ret;

-   dvb_usb_generic_write(d,b,3);
+   if ((ret = dibusb_streaming_ctrl(d,onoff))  0)
+   return ret;

-   return dibusb_streaming_ctrl(d,onoff);
+   if (onoff) {
+   b[0] = DIBUSB_REQ_SET_STREAMING_MODE;
+   b[1] = 0x00;
+   if ((ret = dvb_usb_generic_write(d,b,2))  0)
+   return ret;
+   }
+
+   b[0] = DIBUSB_REQ_SET_IOCTL;
+   b[1] = onoff ? DIBUSB_IOCTL_CMD_ENABLE_STREAM : 
DIBUSB_IOCTL_CMD_DISABLE_STREAM;
+   return dvb_usb_generic_write(d,b,3);
 }
 EXPORT_SYMBOL(dibusb2_0_streaming_ctrl);

Index: linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c
===
RCS file: 
/cvs/linuxtv/dvb-kernel/linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c,v
retrieving revision 1.8
diff -u -r1.8 dvb-usb-dvb.c
--- linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c   2 Jul 2005 12:49:23 
-   1.8
+++ linux/drivers/media/dvb/dvb-usb/dvb-usb-dvb.c   27 Aug 2005 16:56:10 
-
@@ -23,12 +23,12 @@
 */
if (newfeedcount == 0) {
deb_ts(stop feeding\n);
+   dvb_usb_urb_kill(d);

if (d-props.streaming_ctrl != NULL)
if ((ret = d-props.streaming_ctrl(d,0)))
err(error while stopping stream.);

-   dvb_usb_urb_kill(d);
}

d-feedcount = newfeedcount;
@@ -44,6 +44,8 @@
 * for reception.
 */
if (d-feedcount == onoff  d-feedcount  0) {
+   deb_ts(submitting all URBs\n);
+   dvb_usb_urb_submit(d);

deb_ts(controlling pid parser\n);
if (d-props.caps  DVB_USB_HAS_PID_FILTER 
@@ -59,7 +61,6 @@
return -ENODEV;
}

-   dvb_usb_urb_submit(d);
}
return 0;
 }
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb-maintainer] [2.6 patch] Documentation/dvb/get_dvb_firmware: fix firmware URL

2005-08-24 Thread Patrick Boettcher 

On Wed, 24 Aug 2005, Adrian Bunk wrote:


This patch fixes a wrong URL in Documentation/dvb/get_dvb_firmware.


It is already in dvb-kernel CVS. I think it was just not send to Andrew 
along with the latest patchset. Thank you anyway.


best regards,
Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [linux-dvb-maintainer] [2.6 patch] Documentation/dvb/get_dvb_firmware: fix firmware URL

2005-08-24 Thread Patrick Boettcher 

On Wed, 24 Aug 2005, Adrian Bunk wrote:


This patch fixes a wrong URL in Documentation/dvb/get_dvb_firmware.


It is already in dvb-kernel CVS. I think it was just not send to Andrew 
along with the latest patchset. Thank you anyway.


best regards,
Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cx22702.c, 2.6.13-rc3 and a pci Hauppauge Nova-T DVB-T TV card

2005-07-15 Thread Patrick Boettcher 

On Fri, 15 Jul 2005, Mauro Carvalho Chehab wrote:


Patrick,

Patrick Boettcher wrote:

On Fri, 15 Jul 2005, Andrew Benton wrote:


Hi, I tried the patch but unfortunately the kernel didn't compile, it
ended like this

CC  drivers/media/video/cx88/cx88-blackbird.o
CC  drivers/media/video/cx88/cx88-dvb.o
drivers/media/video/cx88/cx88-dvb.c:169: error: unknown field
`output_mode' specified in initializer
drivers/media/video/cx88/cx88-dvb.c:176: error: unknown field
`output_mode' specified in initializer



Yes, I was in a hurry *slap* and made a mistake.

This one is correct (revert the other one):


I've already included this on V4L tree.

On V4L, we do provide support for older 2.6 releases (so, we have some
ifdefs to provide backport compatibility that are removed by a script
before submiting patchsets).
If I understand well your patch, it is to be applied after 2.6.12
version. Am I right?


Yes. 2.6.13-rc1 introduced the cxusb-driver in the kernel and along with 
it the change in the cx22702.


The cx22702.c from video4linux-CVS is not compatible anymore. Not sure how 
you will handle this? (Throw away the cx22702.c and get it from 
dvb-kernel ;) )


best regards,
Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cx22702.c, 2.6.13-rc3 and a pci Hauppauge Nova-T DVB-T TV card

2005-07-15 Thread Patrick Boettcher 

On Fri, 15 Jul 2005, Andrew Benton wrote:
Hi, I tried the patch but unfortunately the kernel didn't compile, it ended 
like this


CC  drivers/media/video/cx88/cx88-blackbird.o
CC  drivers/media/video/cx88/cx88-dvb.o
drivers/media/video/cx88/cx88-dvb.c:169: error: unknown field `output_mode' 
specified in initializer
drivers/media/video/cx88/cx88-dvb.c:176: error: unknown field `output_mode' 
specified in initializer


Yes, I was in a hurry *slap* and made a mistake.

This one is correct (revert the other one):

Index: cx88-dvb.c
===
RCS file: /cvs/video4linux/video4linux/cx88-dvb.c,v
retrieving revision 1.42
diff -u -3 -p -r1.42 cx88-dvb.c
--- cx88-dvb.c  12 Jul 2005 15:44:55 -  1.42
+++ cx88-dvb.c  15 Jul 2005 11:33:48 -
@@ -180,12 +180,14 @@ static struct mt352_config dntv_live_dvb
 #if CONFIG_DVB_CX22702
 static struct cx22702_config connexant_refboard_config = {
.demod_address = 0x43,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.pll_address   = 0x60,
.pll_desc  = _pll_thomson_dtt7579,
 };

 static struct cx22702_config hauppauge_novat_config = {
.demod_address = 0x43,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.pll_address   = 0x61,
.pll_desc  = _pll_thomson_dtt759x,
 };


Sorry,
Patrick.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cx22702.c, 2.6.13-rc3 and a pci Hauppauge Nova-T DVB-T TV card

2005-07-15 Thread Patrick Boettcher 

On Fri, 15 Jul 2005, Johannes Stezenbach wrote:


Andrew Benton wrote:

My pci TV card (a Hauppauge Nova-T DVB-T) works fine with a 2.6.13-rc2
kernel but won't work with a 2.6.13-rc3 by a process of elimination I've
found that if I reverse this part of the 2.6.13-rc3 patch the card works
fine. Please do not include this in the 2.6.13 kernel.


Reversing this patch is not the right fix as it would break
support for the cxusb.c driver. I guess the output_mode needs to
be set for the Hauppauge Nova-T DVB-T (cx88-dvb.c).
cx88-dvb.c is in video4linux CVS, not DVB CVS.

Patrick, can you send a patch for this?


Hmm, yes. When I changed the cx22702-driver to make it work with the
cxusb-driver, I added another field to the struct cx22702_config to
determine the output type.

I was well aware that this breaks support for the PCI cards, that's why I
created a patch for the cx88-dvb.c and posted it the v4l-mailing list and
ask for inclusion.

This was the Mail:
http://www.linuxtv.org/pipermail/linux-dvb/2005-June/002383.html

This is the patch:
Index: cx88-dvb.c
===
RCS file: /cvs/video4linux/video4linux/cx88-dvb.c,v
retrieving revision 1.42
diff -u -3 -p -r1.42 cx88-dvb.c
--- cx88-dvb.c  12 Jul 2005 15:44:55 -  1.42
+++ cx88-dvb.c  15 Jul 2005 11:06:22 -
@@ -166,12 +166,14 @@ static int mt352_pll_set(struct dvb_fron

 static struct mt352_config dvico_fusionhdtv = {
.demod_address = 0x0F,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.demod_init= dvico_fusionhdtv_demod_init,
.pll_set   = mt352_pll_set,
 };

 static struct mt352_config dntv_live_dvbt_config = {
.demod_address = 0x0f,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.demod_init= dntv_live_dvbt_demod_init,
.pll_set   = mt352_pll_set,
 };

Please include. Thanks

Signed-off-by: Patrick Boettcher <[EMAIL PROTECTED]>

best regards,
Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cx22702.c, 2.6.13-rc3 and a pci Hauppauge Nova-T DVB-T TV card

2005-07-15 Thread Patrick Boettcher 

On Fri, 15 Jul 2005, Johannes Stezenbach wrote:


Andrew Benton wrote:

My pci TV card (a Hauppauge Nova-T DVB-T) works fine with a 2.6.13-rc2
kernel but won't work with a 2.6.13-rc3 by a process of elimination I've
found that if I reverse this part of the 2.6.13-rc3 patch the card works
fine. Please do not include this in the 2.6.13 kernel.


Reversing this patch is not the right fix as it would break
support for the cxusb.c driver. I guess the output_mode needs to
be set for the Hauppauge Nova-T DVB-T (cx88-dvb.c).
cx88-dvb.c is in video4linux CVS, not DVB CVS.

Patrick, can you send a patch for this?


Hmm, yes. When I changed the cx22702-driver to make it work with the
cxusb-driver, I added another field to the struct cx22702_config to
determine the output type.

I was well aware that this breaks support for the PCI cards, that's why I
created a patch for the cx88-dvb.c and posted it the v4l-mailing list and
ask for inclusion.

This was the Mail:
http://www.linuxtv.org/pipermail/linux-dvb/2005-June/002383.html

This is the patch:
Index: cx88-dvb.c
===
RCS file: /cvs/video4linux/video4linux/cx88-dvb.c,v
retrieving revision 1.42
diff -u -3 -p -r1.42 cx88-dvb.c
--- cx88-dvb.c  12 Jul 2005 15:44:55 -  1.42
+++ cx88-dvb.c  15 Jul 2005 11:06:22 -
@@ -166,12 +166,14 @@ static int mt352_pll_set(struct dvb_fron

 static struct mt352_config dvico_fusionhdtv = {
.demod_address = 0x0F,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.demod_init= dvico_fusionhdtv_demod_init,
.pll_set   = mt352_pll_set,
 };

 static struct mt352_config dntv_live_dvbt_config = {
.demod_address = 0x0f,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.demod_init= dntv_live_dvbt_demod_init,
.pll_set   = mt352_pll_set,
 };

Please include. Thanks

Signed-off-by: Patrick Boettcher [EMAIL PROTECTED]

best regards,
Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cx22702.c, 2.6.13-rc3 and a pci Hauppauge Nova-T DVB-T TV card

2005-07-15 Thread Patrick Boettcher 

On Fri, 15 Jul 2005, Andrew Benton wrote:
Hi, I tried the patch but unfortunately the kernel didn't compile, it ended 
like this


CC  drivers/media/video/cx88/cx88-blackbird.o
CC  drivers/media/video/cx88/cx88-dvb.o
drivers/media/video/cx88/cx88-dvb.c:169: error: unknown field `output_mode' 
specified in initializer
drivers/media/video/cx88/cx88-dvb.c:176: error: unknown field `output_mode' 
specified in initializer


Yes, I was in a hurry *slap* and made a mistake.

This one is correct (revert the other one):

Index: cx88-dvb.c
===
RCS file: /cvs/video4linux/video4linux/cx88-dvb.c,v
retrieving revision 1.42
diff -u -3 -p -r1.42 cx88-dvb.c
--- cx88-dvb.c  12 Jul 2005 15:44:55 -  1.42
+++ cx88-dvb.c  15 Jul 2005 11:33:48 -
@@ -180,12 +180,14 @@ static struct mt352_config dntv_live_dvb
 #if CONFIG_DVB_CX22702
 static struct cx22702_config connexant_refboard_config = {
.demod_address = 0x43,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.pll_address   = 0x60,
.pll_desc  = dvb_pll_thomson_dtt7579,
 };

 static struct cx22702_config hauppauge_novat_config = {
.demod_address = 0x43,
+   .output_mode   = CX22702_SERIAL_OUTPUT,
.pll_address   = 0x61,
.pll_desc  = dvb_pll_thomson_dtt759x,
 };


Sorry,
Patrick.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: cx22702.c, 2.6.13-rc3 and a pci Hauppauge Nova-T DVB-T TV card

2005-07-15 Thread Patrick Boettcher 

On Fri, 15 Jul 2005, Mauro Carvalho Chehab wrote:


Patrick,

Patrick Boettcher wrote:

On Fri, 15 Jul 2005, Andrew Benton wrote:


Hi, I tried the patch but unfortunately the kernel didn't compile, it
ended like this

CC  drivers/media/video/cx88/cx88-blackbird.o
CC  drivers/media/video/cx88/cx88-dvb.o
drivers/media/video/cx88/cx88-dvb.c:169: error: unknown field
`output_mode' specified in initializer
drivers/media/video/cx88/cx88-dvb.c:176: error: unknown field
`output_mode' specified in initializer



Yes, I was in a hurry *slap* and made a mistake.

This one is correct (revert the other one):


I've already included this on V4L tree.

On V4L, we do provide support for older 2.6 releases (so, we have some
ifdefs to provide backport compatibility that are removed by a script
before submiting patchsets).
If I understand well your patch, it is to be applied after 2.6.12
version. Am I right?


Yes. 2.6.13-rc1 introduced the cxusb-driver in the kernel and along with 
it the change in the cx22702.


The cx22702.c from video4linux-CVS is not compatible anymore. Not sure how 
you will handle this? (Throw away the cx22702.c and get it from 
dvb-kernel ;) )


best regards,
Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/