Re: [PATCH] Fix for hanging si2168 in PCTV 292e, making the code match

[Antti Palosaari]

On 12/14/2017 04:48 PM, Mauro Carvalho Chehab wrote:

Em Tue, 19 Sep 2017 13:13:52 +0100
Nigel Kettlewell  escreveu:


[re-sending as plain text]

Fix for hanging si2168 in PCTV 292e USB, making the code match the comment.

Using firmware v4.0.11 the 292e would work once and then hang on
subsequent attempts to view DVB channels, until physically unplugged and
plugged back in.

With this patch, the warm state is reset for v4.0.11 and it appears to
work both on the first attempt and on subsequent attempts.


It is comment which is wrong. With firmware 4.0.11 it works well without 
need of download it every time. But firmware 4.0.19 needs to be 
downloaded every time after device is put to sleep.

Probably your issue is coming from some other reason.




(Patch basis Linux 4.11.9 f82a53b87594f460f2dd9983eeb851a5840e8df8)


Patch is missing a Signed-off-by. See:
https://elinux.org/Developer_Certificate_Of_Origin).




---
   drivers/media/dvb-frontends/si2168.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 680ba06..523acd1 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -582,7 +582,7 @@ static int si2168_sleep(struct dvb_frontend *fe)
  dev->active = false;

  /* Firmware B 4.0-11 or later loses warm state during sleep */
-   if (dev->version > ('B' << 24 | 4 << 16 | 0 << 8 | 11 << 0))
+   if (dev->version >= ('B' << 24 | 4 << 16 | 0 << 8 | 11 << 0))
  dev->warm = false;

  memcpy(cmd.args, "\x13", 1);
--
2.9.4





Thanks,
Mauro



regards
Antti

--
http://palosaari.fi/

Re: [PATCH] Fix for hanging si2168 in PCTV 292e, making the code match

[Antti Palosaari]

On 12/14/2017 04:48 PM, Mauro Carvalho Chehab wrote:

Em Tue, 19 Sep 2017 13:13:52 +0100
Nigel Kettlewell  escreveu:


[re-sending as plain text]

Fix for hanging si2168 in PCTV 292e USB, making the code match the comment.

Using firmware v4.0.11 the 292e would work once and then hang on
subsequent attempts to view DVB channels, until physically unplugged and
plugged back in.

With this patch, the warm state is reset for v4.0.11 and it appears to
work both on the first attempt and on subsequent attempts.


It is comment which is wrong. With firmware 4.0.11 it works well without 
need of download it every time. But firmware 4.0.19 needs to be 
downloaded every time after device is put to sleep.

Probably your issue is coming from some other reason.




(Patch basis Linux 4.11.9 f82a53b87594f460f2dd9983eeb851a5840e8df8)


Patch is missing a Signed-off-by. See:
https://elinux.org/Developer_Certificate_Of_Origin).




---
   drivers/media/dvb-frontends/si2168.c | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/si2168.c
b/drivers/media/dvb-frontends/si2168.c
index 680ba06..523acd1 100644
--- a/drivers/media/dvb-frontends/si2168.c
+++ b/drivers/media/dvb-frontends/si2168.c
@@ -582,7 +582,7 @@ static int si2168_sleep(struct dvb_frontend *fe)
  dev->active = false;

  /* Firmware B 4.0-11 or later loses warm state during sleep */
-   if (dev->version > ('B' << 24 | 4 << 16 | 0 << 8 | 11 << 0))
+   if (dev->version >= ('B' << 24 | 4 << 16 | 0 << 8 | 11 << 0))
  dev->warm = false;

  memcpy(cmd.args, "\x13", 1);
--
2.9.4





Thanks,
Mauro



regards
Antti

--
http://palosaari.fi/

Re: [media-af9013] question about return value in function af9013_wr_regs()

[Antti Palosaari]

Gustavo A. R. Silva kirjoitti 2017-06-09 00:51:

Hello everybody,

While looking into Coverity ID 1227035 I ran into the following piece
of code at drivers/media/dvb-frontends/af9013.c:595:



The issue here is that the value stored in variable _ret_ at line 608,
 is not being evaluated as it happens at line 662, 667, 672 and 677.
Then after looking into function af9013_wr_regs(), I noticed that this
 function always returns zero, no matter what, as you can see below:

121static int af9013_wr_regs(struct af9013_state *priv, u16 reg, const  
u8 *val,

122int len)
123{
124int ret, i;
125u8 mbox = (0 << 7)|(0 << 6)|(1 << 1)|(1 << 0);
126
127if ((priv->config.ts_mode == AF9013_TS_USB) &&
128((reg & 0xff00) != 0xff00) && ((reg & 0xff00) != 
0xae00)) {

129mbox |= ((len - 1) << 2);
130ret = af9013_wr_regs_i2c(priv, mbox, reg, val, len);
131} else {
132for (i = 0; i < len; i++) {
133ret = af9013_wr_regs_i2c(priv, mbox, reg+i,
 val+i, 1);
134if (ret)
135goto err;
136}
137}
138
139err:
140return 0;
141}


That function should return error code on error case, not zero always.


regards
Antti




--
http://palosaari.fi/

Re: [media-af9013] question about return value in function af9013_wr_regs()

[Antti Palosaari]

Gustavo A. R. Silva kirjoitti 2017-06-09 00:51:

Hello everybody,

While looking into Coverity ID 1227035 I ran into the following piece
of code at drivers/media/dvb-frontends/af9013.c:595:



The issue here is that the value stored in variable _ret_ at line 608,
 is not being evaluated as it happens at line 662, 667, 672 and 677.
Then after looking into function af9013_wr_regs(), I noticed that this
 function always returns zero, no matter what, as you can see below:

121static int af9013_wr_regs(struct af9013_state *priv, u16 reg, const  
u8 *val,

122int len)
123{
124int ret, i;
125u8 mbox = (0 << 7)|(0 << 6)|(1 << 1)|(1 << 0);
126
127if ((priv->config.ts_mode == AF9013_TS_USB) &&
128((reg & 0xff00) != 0xff00) && ((reg & 0xff00) != 
0xae00)) {

129mbox |= ((len - 1) << 2);
130ret = af9013_wr_regs_i2c(priv, mbox, reg, val, len);
131} else {
132for (i = 0; i < len; i++) {
133ret = af9013_wr_regs_i2c(priv, mbox, reg+i,
 val+i, 1);
134if (ret)
135goto err;
136}
137}
138
139err:
140return 0;
141}


That function should return error code on error case, not zero always.


regards
Antti




--
http://palosaari.fi/

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Antti Palosaari]

On 05/15/2017 11:28 PM, Andreas Kemnade wrote:

Hi,

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari <cr...@iki.fi> wrote:


On 03/16/2017 12:22 AM, Andreas Kemnade wrote:

If the si2157 is behind a e.g. si2168, the si2157 will
at least in some situations not be readable after the si268
got the command 0101. It still accepts commands but the answer
is just ff. So read the chip id before that so the
information is not lost.

The following line in kernel output is a symptome
of that problem:
si2157 7-0063: unknown chip version Si21255-\x\x\x

That is hackish solution :( Somehow I2C reads should be get working
rather than making this kind of work-around. Returning 0xff to i2c reads
means that signal strength also shows some wrong static value?


Also this is needed for the Terratec CinergyTC2.
I see the ff even on windows. So it cannot be solved by usb-sniffing of
a working system, so, again how should we proceed?

a) not support dvb sticks which do not work with your preferred
order of initialization.

b) change order of initialisation (maybe optionally add a flag like
INIT_TUNER_BEFORE_DEMOD to avoid risk of breaking other things)

c) something like the current patch.

d) while(!i2c_readable(tuner)) {
  write_random_data_to_demod();
  write_random_data_it9306_bridge();
}
remember_random_data();


There was not much feedback here.


If it is not possible to fix i2c communication then better to add some 
device specific logic to i2c adapter in order to meet demod/tuner 
requirements.





An excerpt from my windows sniff logs:
ep: 02 l:   15 GEN_I2C_WR 00 0603c61201
ep: 02 l:0
ep: 81 l:0
ep: 81 l:5 042300dcff
ep: 02 l:9 GEN_I2C_RD 00 0603c6
ep: 02 l:0
ep: 81 l:0
ep: 81 l:   11 0a240080ff5b02
ep: 02 l:   15 GEN_I2C_WR 00 0603c6140011070300
ep: 02 l:0
ep: 81 l:0
ep: 81 l:5 042500daff
ep: 02 l:9 GEN_I2C_RD 00 0403c6
ep: 02 l:0
ep: 81 l:0
ep: 81 l:9 08260080ff5901

here you see all the  from the device.



Regards,
Andreas



regards
Antti



--
http://palosaari.fi/

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Antti Palosaari]

On 05/15/2017 11:28 PM, Andreas Kemnade wrote:

Hi,

On Sun, 23 Apr 2017 15:19:21 +0300
Antti Palosaari  wrote:


On 03/16/2017 12:22 AM, Andreas Kemnade wrote:

If the si2157 is behind a e.g. si2168, the si2157 will
at least in some situations not be readable after the si268
got the command 0101. It still accepts commands but the answer
is just ff. So read the chip id before that so the
information is not lost.

The following line in kernel output is a symptome
of that problem:
si2157 7-0063: unknown chip version Si21255-\x\x\x

That is hackish solution :( Somehow I2C reads should be get working
rather than making this kind of work-around. Returning 0xff to i2c reads
means that signal strength also shows some wrong static value?


Also this is needed for the Terratec CinergyTC2.
I see the ff even on windows. So it cannot be solved by usb-sniffing of
a working system, so, again how should we proceed?

a) not support dvb sticks which do not work with your preferred
order of initialization.

b) change order of initialisation (maybe optionally add a flag like
INIT_TUNER_BEFORE_DEMOD to avoid risk of breaking other things)

c) something like the current patch.

d) while(!i2c_readable(tuner)) {
  write_random_data_to_demod();
  write_random_data_it9306_bridge();
}
remember_random_data();


There was not much feedback here.


If it is not possible to fix i2c communication then better to add some 
device specific logic to i2c adapter in order to meet demod/tuner 
requirements.





An excerpt from my windows sniff logs:
ep: 02 l:   15 GEN_I2C_WR 00 0603c61201
ep: 02 l:0
ep: 81 l:0
ep: 81 l:5 042300dcff
ep: 02 l:9 GEN_I2C_RD 00 0603c6
ep: 02 l:0
ep: 81 l:0
ep: 81 l:   11 0a240080ff5b02
ep: 02 l:   15 GEN_I2C_WR 00 0603c6140011070300
ep: 02 l:0
ep: 81 l:0
ep: 81 l:5 042500daff
ep: 02 l:9 GEN_I2C_RD 00 0403c6
ep: 02 l:0
ep: 81 l:0
ep: 81 l:9 08260080ff5901

here you see all the  from the device.



Regards,
Andreas



regards
Antti



--
http://palosaari.fi/

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Antti Palosaari]

On 03/16/2017 12:22 AM, Andreas Kemnade wrote:

If the si2157 is behind a e.g. si2168, the si2157 will
at least in some situations not be readable after the si268
got the command 0101. It still accepts commands but the answer
is just ff. So read the chip id before that so the
information is not lost.

The following line in kernel output is a symptome
of that problem:
si2157 7-0063: unknown chip version Si21255-\x\x\x
That is hackish solution :( Somehow I2C reads should be get working 
rather than making this kind of work-around. Returning 0xff to i2c reads 
means that signal strength also shows some wrong static value?


regards
Antti

--
http://palosaari.fi/

Re: [PATCH 1/3] [media] si2157: get chip id during probing

[Antti Palosaari]

On 03/16/2017 12:22 AM, Andreas Kemnade wrote:

If the si2157 is behind a e.g. si2168, the si2157 will
at least in some situations not be readable after the si268
got the command 0101. It still accepts commands but the answer
is just ff. So read the chip id before that so the
information is not lost.

The following line in kernel output is a symptome
of that problem:
si2157 7-0063: unknown chip version Si21255-\x\x\x
That is hackish solution :( Somehow I2C reads should be get working 
rather than making this kind of work-around. Returning 0xff to i2c reads 
means that signal strength also shows some wrong static value?


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v3 0/3] Add support for MyGica T230C DVB-T2 stick

[Antti Palosaari]

On 03/03/2017 08:35 PM, Brüns, Stefan wrote:

On Fr, 2017-02-17 at 01:55 +0100, Stefan Brüns wrote:

The required command sequence for the new tuner (Si2141) was traced
from the
current Windows driver and verified with a small python
script/libusb.
The changes to the Si2168 and dvbsky driver are mostly additions of
the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] dvbsky: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 +++-
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 88
+++
 6 files changed, 118 insertions(+), 2 deletions(-)


Instead of this series, a different patchset was accepted, although
Antti raised concerns about at least 2 of the 3 patches accpeted, more
specifically the si2157 patch contains some bogus initialization code,
and the T230C support were better added to the dvbsky driver instead of
 cxusb.


Patch set looks good. I ordered that device and it arrived yesterday. I 
will handle that during 2 weeks - it is now skiing holiday and I am at 
France alps whole next week. So just wait :)


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v3 0/3] Add support for MyGica T230C DVB-T2 stick

[Antti Palosaari]

On 03/03/2017 08:35 PM, Brüns, Stefan wrote:

On Fr, 2017-02-17 at 01:55 +0100, Stefan Brüns wrote:

The required command sequence for the new tuner (Si2141) was traced
from the
current Windows driver and verified with a small python
script/libusb.
The changes to the Si2168 and dvbsky driver are mostly additions of
the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] dvbsky: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 +++-
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 88
+++
 6 files changed, 118 insertions(+), 2 deletions(-)


Instead of this series, a different patchset was accepted, although
Antti raised concerns about at least 2 of the 3 patches accpeted, more
specifically the si2157 patch contains some bogus initialization code,
and the T230C support were better added to the dvbsky driver instead of
 cxusb.


Patch set looks good. I ordered that device and it arrived yesterday. I 
will handle that during 2 weeks - it is now skiing holiday and I am at 
France alps whole next week. So just wait :)


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

On 02/16/2017 10:48 AM, Antti Palosaari wrote:

On 02/16/2017 01:31 AM, Stefan Bruens wrote:



+/* attach demod */
+memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


You mean sizeof(struct si2168_config) ?


yeah. See chapter 14 from kernel coding style documentation, it handles
issue slightly.


argh, I looked wrong! It is *correct*, do not change it. It is just as 
it should. Sorry about noise.


regards
Antti




--
http://palosaari.fi/

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

On 02/16/2017 10:48 AM, Antti Palosaari wrote:

On 02/16/2017 01:31 AM, Stefan Bruens wrote:



+/* attach demod */
+memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


You mean sizeof(struct si2168_config) ?


yeah. See chapter 14 from kernel coding style documentation, it handles
issue slightly.


argh, I looked wrong! It is *correct*, do not change it. It is just as 
it should. Sorry about noise.


regards
Antti




--
http://palosaari.fi/

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

Hello

On 02/16/2017 01:31 AM, Stefan Bruens wrote:

Hi Antti,

first thanks for for the review. Note the t230c_attach is mostly a copy of the
t330_attach (which is very similar to the t680c_attach), so any of your
comments should probably applied to the other attach functions to have a
common coding style.


Old code could be bad, but imho you could make new code better even it 
makes existing diver coding style slightly inconsistent.




On Mittwoch, 15. Februar 2017 10:27:09 CET Antti Palosaari wrote:

On 02/15/2017 03:51 AM, Stefan Brüns wrote:

[...]

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 02dbc6c45423..729496e5a52e
100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter
*adap)>
return ret;

 }

+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;


you could return ret completely as you don't assign its value runtime


Sure, so something like:

  ...
  return 0;
fail_foo:
  xxx;
fail bar:
  yyy;
  return -ENODEV;

Some of the other attach functions assign ret = -ENODEV and then goto one of
the fail_foo: labels.



+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


You mean sizeof(struct si2168_config) ?


yeah. See chapter 14 from kernel coding style documentation, it handles 
issue slightly.





+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;


it has boolean type


Sure


+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);


I would prefer sizeof dst here too.


Most occurences of similar code in media/usb/ use I2C_NAME_SIZE, found two
occurences of "strlcpy(buf, ..., sizeof(buf)), but of course I can change
this.


+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);


Use module name here. Even it is same than device id on that case, it is
not always the case.


While si2157 driver has several supported chip types, si2168 only supports
si2168 (several revisions). Both request_module("foobar") and
request_module(info.type) are common in media/usb/. Change nevertheless?


+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)


You did not ran checkpatch.pl for that patch? or doesn't it complain
anymore about these?


Checkpatch did not complain.


Indentation seem seems to be wrong (see again coding style doc). Also 
those might fit into single line. And not sure comparing even to NULL, 
at least some point preferred style was !foo, but personally I don't mind.




[...]

@@ -858,6 +946,9 @@ static const struct usb_device_id dvbsky_id_table[] =
{

{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_S2_R4,

_s960_props, "Terratec Cinergy S2 Rev.4",
RC_MAP_DVBSKY) },

+   { DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C,
+   _t230c_props, "Mygica T230C DVB-T/T2/C",


Drop supported DTV standard names from device name. Also it is MyGica
not Mygica.


The print on the stick says: "MyGica(R) DVB-T2", label on the backside says
"T230C". According to the USB descriptors it is a "Geniatech"
"EyeTV Stick". According to the box it is a "MyGica(R)" "Mini DVB-T2 USB Stick
T230C"

Would "MyGica DVB-T2 T230C" be ok?


I would just use device commercial name, which one seems to be most 
official. Geniatech is manufacturer, but commercial brand they sell 
these is MyGica so at least it is not Geniatech EyeTV Stick which is 
something like design name.


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

Hello

On 02/16/2017 01:31 AM, Stefan Bruens wrote:

Hi Antti,

first thanks for for the review. Note the t230c_attach is mostly a copy of the
t330_attach (which is very similar to the t680c_attach), so any of your
comments should probably applied to the other attach functions to have a
common coding style.


Old code could be bad, but imho you could make new code better even it 
makes existing diver coding style slightly inconsistent.




On Mittwoch, 15. Februar 2017 10:27:09 CET Antti Palosaari wrote:

On 02/15/2017 03:51 AM, Stefan Brüns wrote:

[...]

diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c
b/drivers/media/usb/dvb-usb-v2/dvbsky.c index 02dbc6c45423..729496e5a52e
100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter
*adap)>
return ret;

 }

+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;


you could return ret completely as you don't assign its value runtime


Sure, so something like:

  ...
  return 0;
fail_foo:
  xxx;
fail bar:
  yyy;
  return -ENODEV;

Some of the other attach functions assign ret = -ENODEV and then goto one of
the fail_foo: labels.



+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


You mean sizeof(struct si2168_config) ?


yeah. See chapter 14 from kernel coding style documentation, it handles 
issue slightly.





+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;


it has boolean type


Sure


+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);


I would prefer sizeof dst here too.


Most occurences of similar code in media/usb/ use I2C_NAME_SIZE, found two
occurences of "strlcpy(buf, ..., sizeof(buf)), but of course I can change
this.


+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);


Use module name here. Even it is same than device id on that case, it is
not always the case.


While si2157 driver has several supported chip types, si2168 only supports
si2168 (several revisions). Both request_module("foobar") and
request_module(info.type) are common in media/usb/. Change nevertheless?


+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)


You did not ran checkpatch.pl for that patch? or doesn't it complain
anymore about these?


Checkpatch did not complain.


Indentation seem seems to be wrong (see again coding style doc). Also 
those might fit into single line. And not sure comparing even to NULL, 
at least some point preferred style was !foo, but personally I don't mind.




[...]

@@ -858,6 +946,9 @@ static const struct usb_device_id dvbsky_id_table[] =
{

{ DVB_USB_DEVICE(USB_VID_TERRATEC, USB_PID_TERRATEC_CINERGY_S2_R4,

_s960_props, "Terratec Cinergy S2 Rev.4",
RC_MAP_DVBSKY) },

+   { DVB_USB_DEVICE(USB_VID_CONEXANT, USB_PID_MYGICA_T230C,
+   _t230c_props, "Mygica T230C DVB-T/T2/C",


Drop supported DTV standard names from device name. Also it is MyGica
not Mygica.


The print on the stick says: "MyGica(R) DVB-T2", label on the backside says
"T230C". According to the USB descriptors it is a "Geniatech"
"EyeTV Stick". According to the box it is a "MyGica(R)" "Mini DVB-T2 USB Stick
T230C"

Would "MyGica DVB-T2 T230C" be ok?


I would just use device commercial name, which one seems to be most 
official. Geniatech is manufacturer, but commercial brand they sell 
these is MyGica so at least it is not Geniatech EyeTV Stick which is 
something like design name.


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

On 02/15/2017 03:51 AM, Stefan Brüns wrote:

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the other devices supported by the driver,
but uses the Si2141 tuner.
Several DVB-T (MPEG2) and DVB-T2 (H.265) channels were tested, as well as
the include remote control.

Signed-off-by: Stefan Brüns 
---
v2: add support to the dvbsky driver instead of cxusb, correct RC
model
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 91 +++
 2 files changed, 92 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 02dbc6c45423..729496e5a52e 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
return ret;
 }

+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;


you could return ret completely as you don't assign its value runtime


+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;

it has boolean type


+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);

I would prefer sizeof dst here too.


+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);
Use module name here. Even it is same than device id on that case, it is 
not always the case.



+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)


You did not ran checkpatch.pl for that patch? or doesn't it complain 
anymore about these?



+   goto fail_demod_device;
+   if (!try_module_get(client_demod->dev.driver->owner))
+   goto fail_demod_module;
+
+   /* attach tuner */
+   memset(_config, 0, sizeof(si2157_config));
+   si2157_config.fe = adap->fe[0];
+   si2157_config.if_port = 0;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2141", I2C_NAME_SIZE);
+   info.addr = 0x60;
+   info.platform_data = _config;
+
+   request_module("si2157");
+   client_tuner = i2c_new_device(i2c_adapter, );
+   if (client_tuner == NULL ||
+   client_tuner->dev.driver == NULL)
+   goto fail_tuner_device;
+   if (!try_module_get(client_tuner->dev.driver->owner))
+   goto fail_tuner_module;
+
+   state->i2c_client_demod = client_demod;
+   state->i2c_client_tuner = client_tuner;
+   return ret;
+fail_tuner_module:
+   i2c_unregister_device(client_tuner);
+fail_tuner_device:
+   module_put(client_demod->dev.driver->owner);
+fail_demod_module:
+   i2c_unregister_device(client_demod);
+fail_demod_device:
+   ret = -ENODEV;
+   return ret;
+}
+
+
 static int dvbsky_identify_state(struct dvb_usb_device *d, const char **name)
 {
dvbsky_gpio_ctrl(d, 0x04, 1);
@@ -830,6 +892,32 @@ static struct dvb_usb_device_properties dvbsky_t330_props 
= {
}
 };

+static struct dvb_usb_device_properties mygica_t230c_props = {
+   .driver_name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .adapter_nr = adapter_nr,
+   .size_of_priv = sizeof(struct dvbsky_state),
+
+   .generic_bulk_ctrl_endpoint = 0x01,
+   .generic_bulk_ctrl_endpoint_response = 0x81,
+   .generic_bulk_ctrl_delay = DVBSKY_MSG_DELAY,
+
+   .i2c_algo = _i2c_algo,
+   .frontend_attach  = dvbsky_mygica_t230c_attach,
+   .init = dvbsky_init,
+   .get_rc_config= dvbsky_get_rc_config,
+   .streaming_ctrl   = 

Re: [PATCH v2 3/3] [media] dvbsky: MyGica T230C support

[Antti Palosaari]

On 02/15/2017 03:51 AM, Stefan Brüns wrote:

Mygica T230 DVB-T/T2/C USB stick support. It uses the same FX2/Si2168
bridge/demodulator combo as the other devices supported by the driver,
but uses the Si2141 tuner.
Several DVB-T (MPEG2) and DVB-T2 (H.265) channels were tested, as well as
the include remote control.

Signed-off-by: Stefan Brüns 
---
v2: add support to the dvbsky driver instead of cxusb, correct RC
model
---
 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/usb/dvb-usb-v2/dvbsky.c | 91 +++
 2 files changed, 92 insertions(+)

diff --git a/drivers/media/dvb-core/dvb-usb-ids.h 
b/drivers/media/dvb-core/dvb-usb-ids.h
index a7a4674ccc40..ce4a3d574dd7 100644
--- a/drivers/media/dvb-core/dvb-usb-ids.h
+++ b/drivers/media/dvb-core/dvb-usb-ids.h
@@ -380,6 +380,7 @@
 #define USB_PID_SONY_PLAYTV0x0003
 #define USB_PID_MYGICA_D6890xd811
 #define USB_PID_MYGICA_T2300xc688
+#define USB_PID_MYGICA_T230C   0xc689
 #define USB_PID_ELGATO_EYETV_DIVERSITY 0x0011
 #define USB_PID_ELGATO_EYETV_DTT   0x0021
 #define USB_PID_ELGATO_EYETV_DTT_2 0x003f
diff --git a/drivers/media/usb/dvb-usb-v2/dvbsky.c 
b/drivers/media/usb/dvb-usb-v2/dvbsky.c
index 02dbc6c45423..729496e5a52e 100644
--- a/drivers/media/usb/dvb-usb-v2/dvbsky.c
+++ b/drivers/media/usb/dvb-usb-v2/dvbsky.c
@@ -665,6 +665,68 @@ static int dvbsky_t330_attach(struct dvb_usb_adapter *adap)
return ret;
 }

+static int dvbsky_mygica_t230c_attach(struct dvb_usb_adapter *adap)
+{
+   struct dvbsky_state *state = adap_to_priv(adap);
+   struct dvb_usb_device *d = adap_to_d(adap);
+   int ret = 0;


you could return ret completely as you don't assign its value runtime


+   struct i2c_adapter *i2c_adapter;
+   struct i2c_client *client_demod, *client_tuner;
+   struct i2c_board_info info;
+   struct si2168_config si2168_config;
+   struct si2157_config si2157_config;
+
+   /* attach demod */
+   memset(_config, 0, sizeof(si2168_config));


prefer sizeof dst


+   si2168_config.i2c_adapter = _adapter;
+   si2168_config.fe = >fe[0];
+   si2168_config.ts_mode = SI2168_TS_PARALLEL;
+   si2168_config.ts_clock_inv = 1;

it has boolean type


+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2168", I2C_NAME_SIZE);

I would prefer sizeof dst here too.


+   info.addr = 0x64;
+   info.platform_data = _config;
+
+   request_module(info.type);
Use module name here. Even it is same than device id on that case, it is 
not always the case.



+   client_demod = i2c_new_device(>i2c_adap, );
+   if (client_demod == NULL ||
+   client_demod->dev.driver == NULL)


You did not ran checkpatch.pl for that patch? or doesn't it complain 
anymore about these?



+   goto fail_demod_device;
+   if (!try_module_get(client_demod->dev.driver->owner))
+   goto fail_demod_module;
+
+   /* attach tuner */
+   memset(_config, 0, sizeof(si2157_config));
+   si2157_config.fe = adap->fe[0];
+   si2157_config.if_port = 0;
+   memset(, 0, sizeof(struct i2c_board_info));
+   strlcpy(info.type, "si2141", I2C_NAME_SIZE);
+   info.addr = 0x60;
+   info.platform_data = _config;
+
+   request_module("si2157");
+   client_tuner = i2c_new_device(i2c_adapter, );
+   if (client_tuner == NULL ||
+   client_tuner->dev.driver == NULL)
+   goto fail_tuner_device;
+   if (!try_module_get(client_tuner->dev.driver->owner))
+   goto fail_tuner_module;
+
+   state->i2c_client_demod = client_demod;
+   state->i2c_client_tuner = client_tuner;
+   return ret;
+fail_tuner_module:
+   i2c_unregister_device(client_tuner);
+fail_tuner_device:
+   module_put(client_demod->dev.driver->owner);
+fail_demod_module:
+   i2c_unregister_device(client_demod);
+fail_demod_device:
+   ret = -ENODEV;
+   return ret;
+}
+
+
 static int dvbsky_identify_state(struct dvb_usb_device *d, const char **name)
 {
dvbsky_gpio_ctrl(d, 0x04, 1);
@@ -830,6 +892,32 @@ static struct dvb_usb_device_properties dvbsky_t330_props 
= {
}
 };

+static struct dvb_usb_device_properties mygica_t230c_props = {
+   .driver_name = KBUILD_MODNAME,
+   .owner = THIS_MODULE,
+   .adapter_nr = adapter_nr,
+   .size_of_priv = sizeof(struct dvbsky_state),
+
+   .generic_bulk_ctrl_endpoint = 0x01,
+   .generic_bulk_ctrl_endpoint_response = 0x81,
+   .generic_bulk_ctrl_delay = DVBSKY_MSG_DELAY,
+
+   .i2c_algo = _i2c_algo,
+   .frontend_attach  = dvbsky_mygica_t230c_attach,
+   .init = dvbsky_init,
+   .get_rc_config= dvbsky_get_rc_config,
+   .streaming_ctrl   = dvbsky_streaming_ctrl,
+   

Re: [PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

[Antti Palosaari]

On 02/12/2017 05:26 PM, Stefan Brüns wrote:

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)



Patch set looks pretty correct, but remote controller is something I 
hope you could fix. Old T230 did it wrong and defined 
rc_map_d680_dmb_table whilst proper map is 
RC_MAP_TOTAL_MEDIA_IN_HAND_02. Secondly it should be converted to 
rc-core. Even those are wrong for old revision, for new devices those 
should be done correct.


regards
Antti
--
http://palosaari.fi/

Re: [PATCH 0/3] Add support for MyGica T230C DVB-T2 stick

[Antti Palosaari]

On 02/12/2017 05:26 PM, Stefan Brüns wrote:

The required command sequence for the new tuner (Si2141) was traced from the
current Windows driver and verified with a small python script/libusb.
The changes to the Si2168 and cxusb driver are mostly addition of the
required IDs and some glue code.

Stefan Brüns (3):
  [media] si2157: Add support for Si2141-A10
  [media] si2168: add support for Si2168-D60
  [media] cxusb: MyGica T230C support

 drivers/media/dvb-core/dvb-usb-ids.h  |  1 +
 drivers/media/dvb-frontends/si2168.c  |  4 ++
 drivers/media/dvb-frontends/si2168_priv.h |  2 +
 drivers/media/tuners/si2157.c | 23 -
 drivers/media/tuners/si2157_priv.h|  2 +
 drivers/media/usb/dvb-usb/cxusb.c | 80 +--
 6 files changed, 106 insertions(+), 6 deletions(-)



Patch set looks pretty correct, but remote controller is something I 
hope you could fix. Old T230 did it wrong and defined 
rc_map_d680_dmb_table whilst proper map is 
RC_MAP_TOTAL_MEDIA_IN_HAND_02. Secondly it should be converted to 
rc-core. Even those are wrong for old revision, for new devices those 
should be done correct.


regards
Antti
--
http://palosaari.fi/

Re: How should I use kernel-defined i2c structs in this driver

[Antti Palosaari]

On 05/26/2016 04:59 PM, Andrey Utkin wrote:

Could anybody please give a hint - which kernel-defined i2c objects, and how
many of them, I need to define and use to substitute these driver-defined
functions i2c_read(), i2c_write() ?
https://github.com/bluecherrydvr/linux/blob/release/tw5864/1.16/drivers/media/pci/tw5864/tw5864-config.c
In a word, there's 4 chips with different addresses, to which this code
communicates via main chip's dedicated registers.
Do i need a single i2c_adapter or several?
Do i need i2c_client entities?
where should I put what is named "devid" here?

Thanks in advance.


It depends how those are connected at hardware level. Quickly looking I 
think "devid" is here to select proper I2C adapter. So I think there is 
4 I2C adapters and each of those adapter has 1 slave device. Is that 
correct? If yes, then register 4 I2C adapters and register single client 
for each of those adapters.


regards
Antti



--
http://palosaari.fi/

Re: How should I use kernel-defined i2c structs in this driver

[Antti Palosaari]

On 05/26/2016 04:59 PM, Andrey Utkin wrote:

Could anybody please give a hint - which kernel-defined i2c objects, and how
many of them, I need to define and use to substitute these driver-defined
functions i2c_read(), i2c_write() ?
https://github.com/bluecherrydvr/linux/blob/release/tw5864/1.16/drivers/media/pci/tw5864/tw5864-config.c
In a word, there's 4 chips with different addresses, to which this code
communicates via main chip's dedicated registers.
Do i need a single i2c_adapter or several?
Do i need i2c_client entities?
where should I put what is named "devid" here?

Thanks in advance.


It depends how those are connected at hardware level. Quickly looking I 
think "devid" is here to select proper I2C adapter. So I think there is 
4 I2C adapters and each of those adapter has 1 slave device. Is that 
correct? If yes, then register 4 I2C adapters and register single client 
for each of those adapters.


regards
Antti



--
http://palosaari.fi/

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Antti Palosaari]

On 04/29/2016 12:16 PM, Peter Rosin wrote:

On 2016-04-29 09:16, Wolfram Sang wrote:

Yes, obviously... I'll make that change locally and wait for the rest.

Another nit: You could use '--strict' with checkpatch and see if you
want to fix the issues reported. I am not keen on those (except for
'space around operators'), it's a matter of taste I guess, but maybe you
like some of the suggestions.


Yes, they look like reasonable complaints.

So, I fixed all of them locally except the complaint about lack of comment
on the new struct mutex member in struct si2168_dev (patch 21/24),
because that patch is Anttis and he's the maintainer of that driver...

Antti, if you want that fixed as part of this series, send a suitable comment
for the mutex this way and I'll incorporate it.


Ah, I never ran checkpatch with --strict option...

CHECK: struct mutex definition without comment
#202: FILE: drivers/media/dvb-frontends/si2168_priv.h:32:
+   struct mutex i2c_mutex;

If you wish you could add some comment for it, but for me it is still 
pretty much self explaining. It is lock to protect firmware command 
execution. Command is executed always with I2C write and then poll reply 
using I2C read until it timeouts or answers with "ready" status.


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v7 16/24] i2c: allow adapter drivers to override the adapter locking

[Antti Palosaari]

On 04/29/2016 12:16 PM, Peter Rosin wrote:

On 2016-04-29 09:16, Wolfram Sang wrote:

Yes, obviously... I'll make that change locally and wait for the rest.

Another nit: You could use '--strict' with checkpatch and see if you
want to fix the issues reported. I am not keen on those (except for
'space around operators'), it's a matter of taste I guess, but maybe you
like some of the suggestions.


Yes, they look like reasonable complaints.

So, I fixed all of them locally except the complaint about lack of comment
on the new struct mutex member in struct si2168_dev (patch 21/24),
because that patch is Anttis and he's the maintainer of that driver...

Antti, if you want that fixed as part of this series, send a suitable comment
for the mutex this way and I'll incorporate it.


Ah, I never ran checkpatch with --strict option...

CHECK: struct mutex definition without comment
#202: FILE: drivers/media/dvb-frontends/si2168_priv.h:32:
+   struct mutex i2c_mutex;

If you wish you could add some comment for it, but for me it is still 
pretty much self explaining. It is lock to protect firmware command 
execution. Command is executed always with I2C write and then poll reply 
using I2C read until it timeouts or answers with "ready" status.


regards
Antti

--
http://palosaari.fi/

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

[Antti Palosaari]

On 04/20/2016 06:17 PM, Peter Rosin wrote:

Retested all the previously tested + now I tested also cx231xx with 
Hauppauge 930C HD device having eeprom other mux port and demod on the 
other port.



   [media] si2168: change the i2c gate to be mux-locked
   [media] m88ds3103: convert to use an explicit i2c mux core
   [media] rtl2830: convert to use an explicit i2c mux core
   [media] rtl2832: convert to use an explicit i2c mux core
   [media] si2168: convert to use an explicit i2c mux core
   [media] cx231xx: convert to use an explicit i2c mux core
   [media] rtl2832: change the i2c gate to be mux-locked
   [media] rtl2832_sdr: get rid of empty regmap wrappers
   [media] rtl2832: regmap is aware of lockdep, drop local locking hack


I really hope that this whole patch series will arrive asap to mainline.

regards
Antti

--
http://palosaari.fi/

Re: [PATCH v7 00/24] i2c mux cleanup and locking update

[Antti Palosaari]

On 04/20/2016 06:17 PM, Peter Rosin wrote:

Retested all the previously tested + now I tested also cx231xx with 
Hauppauge 930C HD device having eeprom other mux port and demod on the 
other port.



   [media] si2168: change the i2c gate to be mux-locked
   [media] m88ds3103: convert to use an explicit i2c mux core
   [media] rtl2830: convert to use an explicit i2c mux core
   [media] rtl2832: convert to use an explicit i2c mux core
   [media] si2168: convert to use an explicit i2c mux core
   [media] cx231xx: convert to use an explicit i2c mux core
   [media] rtl2832: change the i2c gate to be mux-locked
   [media] rtl2832_sdr: get rid of empty regmap wrappers
   [media] rtl2832: regmap is aware of lockdep, drop local locking hack


I really hope that this whole patch series will arrive asap to mainline.

regards
Antti

--
http://palosaari.fi/

Re: [PATCH v4 00/18] i2c mux cleanup and locking update

[Antti Palosaari]

On 03/15/2016 04:09 PM, Peter Rosin wrote:


The series will be posted again for review. This is just a heads up.

v5 compared to v4:
- Rebase on top of v4.5-rc7.
- A new patch making me maintainer of i2c muxes (also sent separately).
- A new file Documentation/i2c/i2c-topology that describes various muxing
   issues.
- Rename "i2c-controlled" muxes "self-locked" instead, as it is perfectly
   reasonable to have i2c-controlled muxes that use the pre-existing locking
   scheme. The pre-existing locking scheme for i2c muxes is from here on
   called "parent-locked".
- Rename i2c-mux.c:i2c_mux_master_xfer to __i2c_mux_master_xfer since it
   calls __i2c_transfer, which leaves room for a new i2c_mux_master_xfer
   that calls i2c_transfer. Similar rename shuffle for i2c_mux_smbus_xfer.
- Use sizeof(*priv) instead of sizeof(struct i2c_mux_priv). One instance.
- Some follow-up patches that were posted in response to v2-v4 cleaning up
   and simplifying various i2c muxes outside drivers/i2c/, among those is
   an unrelated cleanup patch to drivers/media/dvb-frontends/rtl2832.c that
   I carry here since it conflicts (trivially) with this series. That
   unrelated patch is (currently) the last patch in the series.


The series looks like this now:

The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb:

   Linux 4.5-rc7 (2016-03-06 14:48:03 -0800)

are available in the git repository at:

   https://github.com/peda-r/i2c-mux.git mux-core-and-locking-5


I reviewed and tested these patches:

c1ef4a2 [media] rtl2832: regmap is aware of lockdep, drop local locking hack
6636178 [media] rtl2832_sdr: get rid of empty regmap wrappers
001ad6b [media] rtl2832: declare that the i2c gate is self-locked
e2e82e4 [media] si2168: declare that the i2c gate is self-locked
b52f766 [media] si2168: convert to use an explicit i2c mux core
4ba9115 [media] rtl2832: convert to use an explicit i2c mux core
3f1778b [media] rtl2830: convert to use an explicit i2c mux core
5c8bfc8 [media] m88ds3103: convert to use an explicit i2c mux core


Reviewed-by: Antti Palosaari <cr...@iki.fi>
Tested-by: Antti Palosaari <cr...@iki.fi>

regards
Antti

--
http://palosaari.fi/

Re: [PATCH v4 00/18] i2c mux cleanup and locking update

[Antti Palosaari]

On 03/15/2016 04:09 PM, Peter Rosin wrote:


The series will be posted again for review. This is just a heads up.

v5 compared to v4:
- Rebase on top of v4.5-rc7.
- A new patch making me maintainer of i2c muxes (also sent separately).
- A new file Documentation/i2c/i2c-topology that describes various muxing
   issues.
- Rename "i2c-controlled" muxes "self-locked" instead, as it is perfectly
   reasonable to have i2c-controlled muxes that use the pre-existing locking
   scheme. The pre-existing locking scheme for i2c muxes is from here on
   called "parent-locked".
- Rename i2c-mux.c:i2c_mux_master_xfer to __i2c_mux_master_xfer since it
   calls __i2c_transfer, which leaves room for a new i2c_mux_master_xfer
   that calls i2c_transfer. Similar rename shuffle for i2c_mux_smbus_xfer.
- Use sizeof(*priv) instead of sizeof(struct i2c_mux_priv). One instance.
- Some follow-up patches that were posted in response to v2-v4 cleaning up
   and simplifying various i2c muxes outside drivers/i2c/, among those is
   an unrelated cleanup patch to drivers/media/dvb-frontends/rtl2832.c that
   I carry here since it conflicts (trivially) with this series. That
   unrelated patch is (currently) the last patch in the series.


The series looks like this now:

The following changes since commit f6cede5b49e822ebc41a099fe41ab4989f64e2cb:

   Linux 4.5-rc7 (2016-03-06 14:48:03 -0800)

are available in the git repository at:

   https://github.com/peda-r/i2c-mux.git mux-core-and-locking-5


I reviewed and tested these patches:

c1ef4a2 [media] rtl2832: regmap is aware of lockdep, drop local locking hack
6636178 [media] rtl2832_sdr: get rid of empty regmap wrappers
001ad6b [media] rtl2832: declare that the i2c gate is self-locked
e2e82e4 [media] si2168: declare that the i2c gate is self-locked
b52f766 [media] si2168: convert to use an explicit i2c mux core
4ba9115 [media] rtl2832: convert to use an explicit i2c mux core
3f1778b [media] rtl2830: convert to use an explicit i2c mux core
5c8bfc8 [media] m88ds3103: convert to use an explicit i2c mux core


Reviewed-by: Antti Palosaari 
Tested-by: Antti Palosaari 

regards
Antti

--
http://palosaari.fi/

Re: m88ds3103: Undefined division

[Antti Palosaari]

On 02/19/2016 12:10 PM, Peter Rosin wrote:

Hi!

I'm looking at this code in drivers/media/dvb-frontends/m88ds3103.c in
the m88ds3103_set_frontend() function, line 600 (give or take):

s32tmp = 0x1 * (tuner_frequency - c->frequency);
s32tmp = DIV_ROUND_CLOSEST(s32tmp, priv->mclk_khz);
if (s32tmp < 0)
s32tmp += 0x1;

There is code that tries to handle negative s32tmp, so I assume that
negative s32tmp is a possibility. Further, priv->mclk_khz is an unsigned
type as far as I can tell. But then we have this comment for the
DIV_ROUND_CLOSEST macro:

/*
  * Divide positive or negative dividend by positive divisor and round
  * to closest integer. Result is undefined for negative divisors and
  * for negative dividends if the divisor variable type is unsigned.
  */
#define DIV_ROUND_CLOSEST(x, divisor)(  \

I don't know how bad this is, and what the consequences of garbage are,
but from here it looks like a problem waiting to happen...


Divisor type (mclk) needs to be changed signed then somehow...

regards
Antti

--
http://palosaari.fi/

Re: m88ds3103: Undefined division

[Antti Palosaari]

On 02/19/2016 12:10 PM, Peter Rosin wrote:

Hi!

I'm looking at this code in drivers/media/dvb-frontends/m88ds3103.c in
the m88ds3103_set_frontend() function, line 600 (give or take):

s32tmp = 0x1 * (tuner_frequency - c->frequency);
s32tmp = DIV_ROUND_CLOSEST(s32tmp, priv->mclk_khz);
if (s32tmp < 0)
s32tmp += 0x1;

There is code that tries to handle negative s32tmp, so I assume that
negative s32tmp is a possibility. Further, priv->mclk_khz is an unsigned
type as far as I can tell. But then we have this comment for the
DIV_ROUND_CLOSEST macro:

/*
  * Divide positive or negative dividend by positive divisor and round
  * to closest integer. Result is undefined for negative divisors and
  * for negative dividends if the divisor variable type is unsigned.
  */
#define DIV_ROUND_CLOSEST(x, divisor)(  \

I don't know how bad this is, and what the consequences of garbage are,
but from here it looks like a problem waiting to happen...


Divisor type (mclk) needs to be changed signed then somehow...

regards
Antti

--
http://palosaari.fi/

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

[Antti Palosaari]

On 01/05/2016 05:57 PM, Peter Rosin wrote:

From: Peter Rosin 

Hi!

I have a pair of boards with this i2c topology:

GPIO ---|  -- BAT1
 |  v /
I2C  -+--B---+ MUX
  |   \
EEPROM -- BAT2

(B denotes the boundary between the boards)


Handling of I2C muxes that close channel automatically, after the first 
I2C stop (P) is seen?


For example channel is selected to BAT1 => there is EEPROM write => mux 
closes channel BAT1 => access to BAT1 will fail. Is it possible to lock 
whole adapter, but allow only traffic to i2c mux client?


regards
Antti



The problem with this is that the GPIO controller sits on the same i2c bus
that it MUXes. For pca954x devices this is worked around by using unlocked
transfers when updating the MUX. I have no such luck as the GPIO is a general
purpose IO expander and the MUX is just a random bidirectional MUX, unaware
of the fact that it is muxing an i2c bus, and extending unlocked transfers
into the GPIO subsystem is too ugly to even think about. But the general hw
approach is sane in my opinion, with the number of connections between the
two boards minimized. To put is plainly, I need support for it.

So, I observe that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect operation. The MUX itself needs to be locked, so
transfers to clients behind the mux are serialized, and the MUX needs to be
stable during all i2c traffic (otherwise individual mux slave segments
might see garbage).

This series accomplishes this by adding a dt property to i2c-mux-gpio and
i2c-mux-pinctrl that can be used to state that the mux is updated by means
of the muxed master bus, and that the select-transfer-deselect operations
should be locked individually. When this holds, the i2c bus *is* locked
during muxing, since the muxing happens as part of i2c transfers. This
is true even if the MUX is updated with several transfers to the GPIO (at
least as long as *all* MUX changes are using the i2s master bus). A lock
is added to the mux so that transfers through the mux are serialized.

Concerns:
- The locking is perhaps too complex?
- I worry about the priority inheritance aspect of the adapter lock. When
   the transfers behind the mux are divided into select-transfer-deselect all
   locked individually, low priority transfers get more chances to interfere
   with high priority transfers.
- When doing an i2c_transfer() in_atomic() context of with irqs_disabled(),
   there is a higher possibility that the mux is not returned to its idle
   state after a failed (-EAGAIN) transfer due to trylock.

To summarize the series, there's some i2c-mux infrastructure cleanup work
first (I think that part stands by itself as desireable regardless), the
locking changes are in the last three patches of the series, with the real
meat in 8/8.

PS. needs a bunch of testing, I do not have access to all the involved hw

Changes since v1:
- Allocate mux core and (optional) priv in a combined allocation.
- Killed dev_err messages triggered by memory allocation failure.
- Fix the device specific i2c muxes that I had overlooked.
- Rebased on top of v4.4-rc8 (was based on v4.4-rc6 previously).

Cheers,
Peter

Peter Rosin (8):
   i2c-mux: add common core data for every mux instance
   i2c-mux: move select and deselect ops to i2c_mux_core
   i2c-mux: move the slave side adapter management to i2c_mux_core
   i2c-mux: remove the mux dev pointer from the mux per channel data
   i2c-mux: pinctrl: get rid of the driver private struct device pointer
   i2c: allow adapter drivers to override the adapter locking
   i2c: muxes always lock the parent adapter
   i2c-mux: relax locking of the top i2c adapter during i2c controlled
 muxing

  .../devicetree/bindings/i2c/i2c-mux-gpio.txt   |   2 +
  .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt|   4 +
  drivers/i2c/i2c-core.c |  59 ++---
  drivers/i2c/i2c-mux.c  | 272 +
  drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  46 ++--
  drivers/i2c/muxes/i2c-mux-gpio.c   |  58 ++---
  drivers/i2c/muxes/i2c-mux-pca9541.c|  58 +++--
  drivers/i2c/muxes/i2c-mux-pca954x.c|  66 ++---
  drivers/i2c/muxes/i2c-mux-pinctrl.c|  89 +++
  drivers/i2c/muxes/i2c-mux-reg.c|  63 ++---
  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |  33 +--
  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |   2 +-
  drivers/media/dvb-frontends/m88ds3103.c|  23 +-
  drivers/media/dvb-frontends/m88ds3103_priv.h   |   2 +-
  drivers/media/dvb-frontends/rtl2830.c  |  24 +-
  

Re: [PATCH v2 0/8] i2c mux cleanup and locking update

[Antti Palosaari]

On 01/05/2016 05:57 PM, Peter Rosin wrote:

From: Peter Rosin 

Hi!

I have a pair of boards with this i2c topology:

GPIO ---|  -- BAT1
 |  v /
I2C  -+--B---+ MUX
  |   \
EEPROM -- BAT2

(B denotes the boundary between the boards)


Handling of I2C muxes that close channel automatically, after the first 
I2C stop (P) is seen?


For example channel is selected to BAT1 => there is EEPROM write => mux 
closes channel BAT1 => access to BAT1 will fail. Is it possible to lock 
whole adapter, but allow only traffic to i2c mux client?


regards
Antti



The problem with this is that the GPIO controller sits on the same i2c bus
that it MUXes. For pca954x devices this is worked around by using unlocked
transfers when updating the MUX. I have no such luck as the GPIO is a general
purpose IO expander and the MUX is just a random bidirectional MUX, unaware
of the fact that it is muxing an i2c bus, and extending unlocked transfers
into the GPIO subsystem is too ugly to even think about. But the general hw
approach is sane in my opinion, with the number of connections between the
two boards minimized. To put is plainly, I need support for it.

So, I observe that while it is needed to have the i2c bus locked during the
actual MUX update in order to avoid random garbage on the slave side, it
is not strictly a must to have it locked over the whole sequence of a full
select-transfer-deselect operation. The MUX itself needs to be locked, so
transfers to clients behind the mux are serialized, and the MUX needs to be
stable during all i2c traffic (otherwise individual mux slave segments
might see garbage).

This series accomplishes this by adding a dt property to i2c-mux-gpio and
i2c-mux-pinctrl that can be used to state that the mux is updated by means
of the muxed master bus, and that the select-transfer-deselect operations
should be locked individually. When this holds, the i2c bus *is* locked
during muxing, since the muxing happens as part of i2c transfers. This
is true even if the MUX is updated with several transfers to the GPIO (at
least as long as *all* MUX changes are using the i2s master bus). A lock
is added to the mux so that transfers through the mux are serialized.

Concerns:
- The locking is perhaps too complex?
- I worry about the priority inheritance aspect of the adapter lock. When
   the transfers behind the mux are divided into select-transfer-deselect all
   locked individually, low priority transfers get more chances to interfere
   with high priority transfers.
- When doing an i2c_transfer() in_atomic() context of with irqs_disabled(),
   there is a higher possibility that the mux is not returned to its idle
   state after a failed (-EAGAIN) transfer due to trylock.

To summarize the series, there's some i2c-mux infrastructure cleanup work
first (I think that part stands by itself as desireable regardless), the
locking changes are in the last three patches of the series, with the real
meat in 8/8.

PS. needs a bunch of testing, I do not have access to all the involved hw

Changes since v1:
- Allocate mux core and (optional) priv in a combined allocation.
- Killed dev_err messages triggered by memory allocation failure.
- Fix the device specific i2c muxes that I had overlooked.
- Rebased on top of v4.4-rc8 (was based on v4.4-rc6 previously).

Cheers,
Peter

Peter Rosin (8):
   i2c-mux: add common core data for every mux instance
   i2c-mux: move select and deselect ops to i2c_mux_core
   i2c-mux: move the slave side adapter management to i2c_mux_core
   i2c-mux: remove the mux dev pointer from the mux per channel data
   i2c-mux: pinctrl: get rid of the driver private struct device pointer
   i2c: allow adapter drivers to override the adapter locking
   i2c: muxes always lock the parent adapter
   i2c-mux: relax locking of the top i2c adapter during i2c controlled
 muxing

  .../devicetree/bindings/i2c/i2c-mux-gpio.txt   |   2 +
  .../devicetree/bindings/i2c/i2c-mux-pinctrl.txt|   4 +
  drivers/i2c/i2c-core.c |  59 ++---
  drivers/i2c/i2c-mux.c  | 272 +
  drivers/i2c/muxes/i2c-arb-gpio-challenge.c |  46 ++--
  drivers/i2c/muxes/i2c-mux-gpio.c   |  58 ++---
  drivers/i2c/muxes/i2c-mux-pca9541.c|  58 +++--
  drivers/i2c/muxes/i2c-mux-pca954x.c|  66 ++---
  drivers/i2c/muxes/i2c-mux-pinctrl.c|  89 +++
  drivers/i2c/muxes/i2c-mux-reg.c|  63 ++---
  drivers/iio/imu/inv_mpu6050/inv_mpu_core.c |  33 +--
  drivers/iio/imu/inv_mpu6050/inv_mpu_iio.h  |   2 +-
  drivers/media/dvb-frontends/m88ds3103.c|  23 +-
  drivers/media/dvb-frontends/m88ds3103_priv.h   |   2 +-
  drivers/media/dvb-frontends/rtl2830.c  |  24 +-
  

Re: [PATCH] [media] hackrf: don't emit dev debug on a kfree'd or null dev

[Antti Palosaari]

On 11/11/2015 05:05 PM, Colin King wrote:

From: Colin Ian King 

Static analysis with smatch detected a couple of issues:

drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe()
   error: we previously assumed 'dev' could be null (see line 1366)
drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe()
   error: dereferencing freed memory 'dev'

A dev_dbg message is being output on a kfree'd dev.  Worse, if dev
is not allocated earlier, on, a null pointer deference on dev->dev
can occur onthe deb_dbg call.  Clean this up by only printing a debug
message if dev is not null and has not been kfree'd.


It is already fixed:
https://patchwork.linuxtv.org/patch/31712/



Signed-off-by: Colin Ian King 
---
  drivers/media/usb/hackrf/hackrf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/hackrf/hackrf.c 
b/drivers/media/usb/hackrf/hackrf.c
index e05bfec..faf3670 100644
--- a/drivers/media/usb/hackrf/hackrf.c
+++ b/drivers/media/usb/hackrf/hackrf.c
@@ -1528,9 +1528,9 @@ err_v4l2_ctrl_handler_free_tx:
  err_v4l2_ctrl_handler_free_rx:
v4l2_ctrl_handler_free(>rx_ctrl_handler);
  err_kfree:
+   dev_dbg(dev->dev, "failed=%d\n", ret);
kfree(dev);
  err:
-   dev_dbg(dev->dev, "failed=%d\n", ret);
return ret;
  }




regards
Antti




--
http://palosaari.fi/
--
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] [media] hackrf: don't emit dev debug on a kfree'd or null dev

[Antti Palosaari]

On 11/11/2015 05:05 PM, Colin King wrote:

From: Colin Ian King 

Static analysis with smatch detected a couple of issues:

drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe()
   error: we previously assumed 'dev' could be null (see line 1366)
drivers/media/usb/hackrf/hackrf.c:1533 hackrf_probe()
   error: dereferencing freed memory 'dev'

A dev_dbg message is being output on a kfree'd dev.  Worse, if dev
is not allocated earlier, on, a null pointer deference on dev->dev
can occur onthe deb_dbg call.  Clean this up by only printing a debug
message if dev is not null and has not been kfree'd.


It is already fixed:
https://patchwork.linuxtv.org/patch/31712/



Signed-off-by: Colin Ian King 
---
  drivers/media/usb/hackrf/hackrf.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/usb/hackrf/hackrf.c 
b/drivers/media/usb/hackrf/hackrf.c
index e05bfec..faf3670 100644
--- a/drivers/media/usb/hackrf/hackrf.c
+++ b/drivers/media/usb/hackrf/hackrf.c
@@ -1528,9 +1528,9 @@ err_v4l2_ctrl_handler_free_tx:
  err_v4l2_ctrl_handler_free_rx:
v4l2_ctrl_handler_free(>rx_ctrl_handler);
  err_kfree:
+   dev_dbg(dev->dev, "failed=%d\n", ret);
kfree(dev);
  err:
-   dev_dbg(dev->dev, "failed=%d\n", ret);
return ret;
  }




regards
Antti




--
http://palosaari.fi/
--
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 2/2] ts2020: Provide DVBv5 API signal strength

[Antti Palosaari]

On 06/03/2015 07:37 PM, David Howells wrote:

Malcolm Priestley  wrote:


Yes, also, the workqueue appears not to be initialized when using the dvb
attached method.


I'm not sure what you're referring to.  It's initialised in ts2020_probe()
just after the ts2020_priv struct is allocated - the only place it is
allocated.


ts2020_probe() isn't touched by devices not converted to I2C binding.


Hmmm...  Doesn't that expose a larger problem?  The only place the ts2020_priv
struct is allocated is in ts2020_probe() within ts2020.c and the struct
definition is private to that file and so it can't be allocated from outside.
So if you don't pass through ts2020_probe(), fe->tuner_priv will remain NULL
and the driver will crash.


Malcolm misses some pending patches where attach() is wrapped to I2C 
model probe().

http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=ts2020

regards
Antti

--
http://palosaari.fi/
--
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 2/2] ts2020: Provide DVBv5 API signal strength

[Antti Palosaari]

On 05/28/2015 11:07 PM, Malcolm Priestley wrote:

On 28/05/15 11:08, David Howells wrote:

Malcolm Priestley  wrote:


Statistics polling can not be done by lmedm04 driver's implementation of
M88RS2000/TS2020 because I2C messages stop the devices demuxer.


I did make tests (using that same lme2510 + rs2000 device) and didn't 
saw the issue TS was lost. Could test and and tell me how to reproduce it?
Signal strength returned was quite boring though, about same value all 
the time, but it is different issue...




So any polling must be a config option for this driver.


Ummm...  I presume a runtime config option is okay.


Yes, also, the workqueue appears not to be initialized when using the
dvb attached method.



Also, does that mean that the lmedm04 driver can't be made compatible
with the
DVBv5 API?


No, the driver will have to implement its own version. It doesn't need a
polling thread it simply gets it directly from its interrupt urb buffer.


I assume lme2510 firmware will read signal strength from rs2000 and it 
is returned then directly by USB interface.


regards
Antti

--
http://palosaari.fi/
--
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 2/2] ts2020: Provide DVBv5 API signal strength

[Antti Palosaari]

On 05/28/2015 11:07 PM, Malcolm Priestley wrote:

On 28/05/15 11:08, David Howells wrote:

Malcolm Priestley tvbox...@gmail.com wrote:


Statistics polling can not be done by lmedm04 driver's implementation of
M88RS2000/TS2020 because I2C messages stop the devices demuxer.


I did make tests (using that same lme2510 + rs2000 device) and didn't 
saw the issue TS was lost. Could test and and tell me how to reproduce it?
Signal strength returned was quite boring though, about same value all 
the time, but it is different issue...




So any polling must be a config option for this driver.


Ummm...  I presume a runtime config option is okay.


Yes, also, the workqueue appears not to be initialized when using the
dvb attached method.



Also, does that mean that the lmedm04 driver can't be made compatible
with the
DVBv5 API?


No, the driver will have to implement its own version. It doesn't need a
polling thread it simply gets it directly from its interrupt urb buffer.


I assume lme2510 firmware will read signal strength from rs2000 and it 
is returned then directly by USB interface.


regards
Antti

--
http://palosaari.fi/
--
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 2/2] ts2020: Provide DVBv5 API signal strength

[Antti Palosaari]

On 06/03/2015 07:37 PM, David Howells wrote:

Malcolm Priestley tvbox...@gmail.com wrote:


Yes, also, the workqueue appears not to be initialized when using the dvb
attached method.


I'm not sure what you're referring to.  It's initialised in ts2020_probe()
just after the ts2020_priv struct is allocated - the only place it is
allocated.


ts2020_probe() isn't touched by devices not converted to I2C binding.


Hmmm...  Doesn't that expose a larger problem?  The only place the ts2020_priv
struct is allocated is in ts2020_probe() within ts2020.c and the struct
definition is private to that file and so it can't be allocated from outside.
So if you don't pass through ts2020_probe(), fe-tuner_priv will remain NULL
and the driver will crash.


Malcolm misses some pending patches where attach() is wrapped to I2C 
model probe().

http://git.linuxtv.org/cgit.cgi/anttip/media_tree.git/log/?h=ts2020

regards
Antti

--
http://palosaari.fi/
--
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] m88ts2022: Nested loops shouldn't use the same index variable

[Antti Palosaari]

On 03/20/2015 03:37 PM, David Howells wrote:

There are a pair of nested loops inside m88ts2022_cmd() that use the same
index variable, but for different things.  Split the variable.

Signed-off-by: David Howells 


Reviewed-by: Antti Palosaari 

regards
Antti


---

  drivers/media/tuners/m88ts2022.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/tuners/m88ts2022.c b/drivers/media/tuners/m88ts2022.c
index 066e543..cdf9fe5 100644
--- a/drivers/media/tuners/m88ts2022.c
+++ b/drivers/media/tuners/m88ts2022.c
@@ -21,7 +21,7 @@
  static int m88ts2022_cmd(struct m88ts2022_dev *dev, int op, int sleep, u8 reg,
u8 mask, u8 val, u8 *reg_val)
  {
-   int ret, i;
+   int ret, i, j;
unsigned int utmp;
struct m88ts2022_reg_val reg_vals[] = {
{0x51, 0x1f - op},
@@ -35,9 +35,9 @@ static int m88ts2022_cmd(struct m88ts2022_dev *dev, int op, 
int sleep, u8 reg,
"i=%d op=%02x reg=%02x mask=%02x val=%02x\n",
i, op, reg, mask, val);

-   for (i = 0; i < ARRAY_SIZE(reg_vals); i++) {
-   ret = regmap_write(dev->regmap, reg_vals[i].reg,
-   reg_vals[i].val);
+   for (j = 0; j < ARRAY_SIZE(reg_vals); j++) {
+   ret = regmap_write(dev->regmap, reg_vals[j].reg,
+   reg_vals[j].val);
if (ret)
goto err;
}

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



--
http://palosaari.fi/
--
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 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Antti Palosaari]

On 03/20/2015 01:14 PM, Javi Merino wrote:

Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Antti Palosaari 
Cc: Mauro Carvalho Chehab 
Signed-off-by: Javi Merino 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 


Antti


---
I've only compile-tested it, I don't have the hardware to run it.

  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
  5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index 149fdca3fb44..72b0e2db3aab 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz => kHz */
num *= 0x4000;
-   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = (if_ctl >> 8) & 0x3f;
buf[1] = (if_ctl >> 0) & 0xff;

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 422e84bbb008..490e090048ef 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -244,12 +244,6 @@ error:
return ret;
  }

-/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
  {
struct cxd2820r_priv *priv = fe->demodulator_priv;
diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
b/drivers/media/dvb-frontends/cxd2820r_priv.h
index 7ff5f60c83e1..4b428959b16e 100644
--- a/drivers/media/dvb-frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
@@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 reg, 
u8 val,
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
-
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
b/drivers/media/dvb-frontends/cxd2820r_t.c
index 51401d036530..008cb2ac8480 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t.c
@@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz => kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl >> 16) & 0xff);
buf[1] = ((if_ctl >>  8) & 0xff);
buf[2] = ((if_ctl >>  0) & 0xff);
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index 9c0c4f42175c..35fe364c7182 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz => kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl >> 16) & 0xff);
buf[1] = ((if_ctl >>  8) & 0xff);
buf[2] = ((if_ctl >>  0) & 0xff);



--
http://palosaari.fi/
--
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 4/4] media: cxd2820r: use DIV_ROUND_CLOSEST_ULL()

[Antti Palosaari]

On 03/20/2015 01:14 PM, Javi Merino wrote:

Now that the kernel provides DIV_ROUND_CLOSEST_ULL(), drop the internal
implementation and use the kernel one.

Cc: Antti Palosaari cr...@iki.fi
Cc: Mauro Carvalho Chehab mche...@osg.samsung.com
Signed-off-by: Javi Merino javi.mer...@arm.com


Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi


Antti


---
I've only compile-tested it, I don't have the hardware to run it.

  drivers/media/dvb-frontends/cxd2820r_c.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_core.c | 6 --
  drivers/media/dvb-frontends/cxd2820r_priv.h | 2 --
  drivers/media/dvb-frontends/cxd2820r_t.c| 2 +-
  drivers/media/dvb-frontends/cxd2820r_t2.c   | 2 +-
  5 files changed, 3 insertions(+), 11 deletions(-)

diff --git a/drivers/media/dvb-frontends/cxd2820r_c.c 
b/drivers/media/dvb-frontends/cxd2820r_c.c
index 149fdca3fb44..72b0e2db3aab 100644
--- a/drivers/media/dvb-frontends/cxd2820r_c.c
+++ b/drivers/media/dvb-frontends/cxd2820r_c.c
@@ -79,7 +79,7 @@ int cxd2820r_set_frontend_c(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz = kHz */
num *= 0x4000;
-   if_ctl = 0x4000 - cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = 0x4000 - DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = (if_ctl  8)  0x3f;
buf[1] = (if_ctl  0)  0xff;

diff --git a/drivers/media/dvb-frontends/cxd2820r_core.c 
b/drivers/media/dvb-frontends/cxd2820r_core.c
index 422e84bbb008..490e090048ef 100644
--- a/drivers/media/dvb-frontends/cxd2820r_core.c
+++ b/drivers/media/dvb-frontends/cxd2820r_core.c
@@ -244,12 +244,6 @@ error:
return ret;
  }

-/* 64 bit div with round closest, like DIV_ROUND_CLOSEST but 64 bit */
-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor)
-{
-   return div_u64(dividend + (divisor / 2), divisor);
-}
-
  static int cxd2820r_set_frontend(struct dvb_frontend *fe)
  {
struct cxd2820r_priv *priv = fe-demodulator_priv;
diff --git a/drivers/media/dvb-frontends/cxd2820r_priv.h 
b/drivers/media/dvb-frontends/cxd2820r_priv.h
index 7ff5f60c83e1..4b428959b16e 100644
--- a/drivers/media/dvb-frontends/cxd2820r_priv.h
+++ b/drivers/media/dvb-frontends/cxd2820r_priv.h
@@ -64,8 +64,6 @@ int cxd2820r_wr_reg_mask(struct cxd2820r_priv *priv, u32 reg, 
u8 val,
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

-u32 cxd2820r_div_u64_round_closest(u64 dividend, u32 divisor);
-
  int cxd2820r_wr_regs(struct cxd2820r_priv *priv, u32 reginfo, u8 *val,
int len);

diff --git a/drivers/media/dvb-frontends/cxd2820r_t.c 
b/drivers/media/dvb-frontends/cxd2820r_t.c
index 51401d036530..008cb2ac8480 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t.c
@@ -103,7 +103,7 @@ int cxd2820r_set_frontend_t(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz = kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl  16)  0xff);
buf[1] = ((if_ctl   8)  0xff);
buf[2] = ((if_ctl   0)  0xff);
diff --git a/drivers/media/dvb-frontends/cxd2820r_t2.c 
b/drivers/media/dvb-frontends/cxd2820r_t2.c
index 9c0c4f42175c..35fe364c7182 100644
--- a/drivers/media/dvb-frontends/cxd2820r_t2.c
+++ b/drivers/media/dvb-frontends/cxd2820r_t2.c
@@ -120,7 +120,7 @@ int cxd2820r_set_frontend_t2(struct dvb_frontend *fe)

num = if_freq / 1000; /* Hz = kHz */
num *= 0x100;
-   if_ctl = cxd2820r_div_u64_round_closest(num, 41000);
+   if_ctl = DIV_ROUND_CLOSEST_ULL(num, 41000);
buf[0] = ((if_ctl  16)  0xff);
buf[1] = ((if_ctl   8)  0xff);
buf[2] = ((if_ctl   0)  0xff);



--
http://palosaari.fi/
--
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] m88ts2022: Nested loops shouldn't use the same index variable

[Antti Palosaari]

On 03/20/2015 03:37 PM, David Howells wrote:

There are a pair of nested loops inside m88ts2022_cmd() that use the same
index variable, but for different things.  Split the variable.

Signed-off-by: David Howells dhowe...@redhat.com


Reviewed-by: Antti Palosaari cr...@iki.fi

regards
Antti


---

  drivers/media/tuners/m88ts2022.c |8 
  1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/media/tuners/m88ts2022.c b/drivers/media/tuners/m88ts2022.c
index 066e543..cdf9fe5 100644
--- a/drivers/media/tuners/m88ts2022.c
+++ b/drivers/media/tuners/m88ts2022.c
@@ -21,7 +21,7 @@
  static int m88ts2022_cmd(struct m88ts2022_dev *dev, int op, int sleep, u8 reg,
u8 mask, u8 val, u8 *reg_val)
  {
-   int ret, i;
+   int ret, i, j;
unsigned int utmp;
struct m88ts2022_reg_val reg_vals[] = {
{0x51, 0x1f - op},
@@ -35,9 +35,9 @@ static int m88ts2022_cmd(struct m88ts2022_dev *dev, int op, 
int sleep, u8 reg,
i=%d op=%02x reg=%02x mask=%02x val=%02x\n,
i, op, reg, mask, val);

-   for (i = 0; i  ARRAY_SIZE(reg_vals); i++) {
-   ret = regmap_write(dev-regmap, reg_vals[i].reg,
-   reg_vals[i].val);
+   for (j = 0; j  ARRAY_SIZE(reg_vals); j++) {
+   ret = regmap_write(dev-regmap, reg_vals[j].reg,
+   reg_vals[j].val);
if (ret)
goto err;
}

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



--
http://palosaari.fi/
--
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] si2168: tda10071: m88ds3103: Fix trivial typos

[Antti Palosaari]

On 02/26/2015 12:13 PM, Yannick Guerrini wrote:

Change 'firmare' to 'firmware'

Signed-off-by: Yannick Guerrini 


Acked-by: Antti Palosaari 

Antti


---
  drivers/media/dvb-frontends/m88ds3103.c | 2 +-
  drivers/media/dvb-frontends/si2168_priv.h   | 2 +-
  drivers/media/dvb-frontends/tda10071_priv.h | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
b/drivers/media/dvb-frontends/m88ds3103.c
index ba4ee0b..d3d928e 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -630,7 +630,7 @@ static int m88ds3103_init(struct dvb_frontend *fe)
/* request the firmware, this will block and timeout */
ret = request_firmware(, fw_file, priv->i2c->dev.parent);
if (ret) {
-   dev_err(>i2c->dev, "%s: firmare file '%s' not found\n",
+   dev_err(>i2c->dev, "%s: firmware file '%s' not found\n",
KBUILD_MODNAME, fw_file);
goto err;
}
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index aadd136..d7efce8 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -40,7 +40,7 @@ struct si2168_dev {
bool ts_clock_inv;
  };

-/* firmare command struct */
+/* firmware command struct */
  #define SI2168_ARGLEN  30
  struct si2168_cmd {
u8 args[SI2168_ARGLEN];
diff --git a/drivers/media/dvb-frontends/tda10071_priv.h 
b/drivers/media/dvb-frontends/tda10071_priv.h
index 4204861..03f839c 100644
--- a/drivers/media/dvb-frontends/tda10071_priv.h
+++ b/drivers/media/dvb-frontends/tda10071_priv.h
@@ -99,7 +99,7 @@ struct tda10071_reg_val_mask {
  #define CMD_BER_CONTROL 0x3e
  #define CMD_BER_UPDATE_COUNTERS 0x3f

-/* firmare command struct */
+/* firmware command struct */
  #define TDA10071_ARGLEN  30
  struct tda10071_cmd {
u8 args[TDA10071_ARGLEN];



--
http://palosaari.fi/
--
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] si2168: tda10071: m88ds3103: Fix trivial typos

[Antti Palosaari]

On 02/26/2015 12:13 PM, Yannick Guerrini wrote:

Change 'firmare' to 'firmware'

Signed-off-by: Yannick Guerrini yguerr...@tomshardware.fr


Acked-by: Antti Palosaari cr...@iki.fi

Antti


---
  drivers/media/dvb-frontends/m88ds3103.c | 2 +-
  drivers/media/dvb-frontends/si2168_priv.h   | 2 +-
  drivers/media/dvb-frontends/tda10071_priv.h | 2 +-
  3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/m88ds3103.c 
b/drivers/media/dvb-frontends/m88ds3103.c
index ba4ee0b..d3d928e 100644
--- a/drivers/media/dvb-frontends/m88ds3103.c
+++ b/drivers/media/dvb-frontends/m88ds3103.c
@@ -630,7 +630,7 @@ static int m88ds3103_init(struct dvb_frontend *fe)
/* request the firmware, this will block and timeout */
ret = request_firmware(fw, fw_file, priv-i2c-dev.parent);
if (ret) {
-   dev_err(priv-i2c-dev, %s: firmare file '%s' not found\n,
+   dev_err(priv-i2c-dev, %s: firmware file '%s' not found\n,
KBUILD_MODNAME, fw_file);
goto err;
}
diff --git a/drivers/media/dvb-frontends/si2168_priv.h 
b/drivers/media/dvb-frontends/si2168_priv.h
index aadd136..d7efce8 100644
--- a/drivers/media/dvb-frontends/si2168_priv.h
+++ b/drivers/media/dvb-frontends/si2168_priv.h
@@ -40,7 +40,7 @@ struct si2168_dev {
bool ts_clock_inv;
  };

-/* firmare command struct */
+/* firmware command struct */
  #define SI2168_ARGLEN  30
  struct si2168_cmd {
u8 args[SI2168_ARGLEN];
diff --git a/drivers/media/dvb-frontends/tda10071_priv.h 
b/drivers/media/dvb-frontends/tda10071_priv.h
index 4204861..03f839c 100644
--- a/drivers/media/dvb-frontends/tda10071_priv.h
+++ b/drivers/media/dvb-frontends/tda10071_priv.h
@@ -99,7 +99,7 @@ struct tda10071_reg_val_mask {
  #define CMD_BER_CONTROL 0x3e
  #define CMD_BER_UPDATE_COUNTERS 0x3f

-/* firmare command struct */
+/* firmware command struct */
  #define TDA10071_ARGLEN  30
  struct tda10071_cmd {
u8 args[TDA10071_ARGLEN];



--
http://palosaari.fi/
--
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 v2] rtl2832: remove compiler warning

[Antti Palosaari]

On 02/11/2015 01:08 PM, Luis de Bethencourt wrote:

Cleaning up the following compiler warning:
rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function

Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
tmp, this line would never run because we go to err. It is still nice to avoid
compiler warnings.

Signed-off-by: Luis de Bethencourt 



Reviewed-by: Antti Palosaari 

Antti


---
  drivers/media/dvb-frontends/rtl2832.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 5d2d8f4..20fa245 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, 
fe_status_t *status)
struct rtl2832_dev *dev = fe->demodulator_priv;
struct i2c_client *client = dev->client;
int ret;
-   u32 tmp;
+   u32 uninitialized_var(tmp);

dev_dbg(>dev, "\n");




--
http://palosaari.fi/
--
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 v2] rtl2832: remove compiler warning

[Antti Palosaari]

On 02/11/2015 01:08 PM, Luis de Bethencourt wrote:

Cleaning up the following compiler warning:
rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function

Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
tmp, this line would never run because we go to err. It is still nice to avoid
compiler warnings.

Signed-off-by: Luis de Bethencourt luis...@samsung.com



Reviewed-by: Antti Palosaari cr...@iki.fi

Antti


---
  drivers/media/dvb-frontends/rtl2832.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 5d2d8f4..20fa245 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, 
fe_status_t *status)
struct rtl2832_dev *dev = fe-demodulator_priv;
struct i2c_client *client = dev-client;
int ret;
-   u32 tmp;
+   u32 uninitialized_var(tmp);

dev_dbg(client-dev, \n);




--
http://palosaari.fi/
--
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] rtl2832: remove compiler warning

[Antti Palosaari]

On 02/09/2015 12:44 AM, Luis de Bethencourt wrote:

Cleaning the following compiler warning:
rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function

Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
tmp, this line would never run because we go to err. It is still nice to avoid
compiler warnings.

Signed-off-by: Luis de Bethencourt 
---
  drivers/media/dvb-frontends/rtl2832.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 5d2d8f4..ad36d1c 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, 
fe_status_t *status)
struct rtl2832_dev *dev = fe->demodulator_priv;
struct i2c_client *client = dev->client;
int ret;
-   u32 tmp;
+   u32 tmp = 0;

dev_dbg(>dev, "\n");


I looked the code and I cannot see how it could used as uninitialized. 
Dunno how it could be fixed properly.


Also, I think idiom to say compiler that variable could be uninitialized 
is to store its own value. But I am fine with zero initialization too.


u32 tmp = tmp;

regards
Antti

--
http://palosaari.fi/
--
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] rtl2832: remove compiler warning

[Antti Palosaari]

On 02/09/2015 12:44 AM, Luis de Bethencourt wrote:

Cleaning the following compiler warning:
rtl2832.c:703:12: warning: 'tmp' may be used uninitialized in this function

Even though it could never happen since if rtl2832_rd_demod_reg () doesn't set
tmp, this line would never run because we go to err. It is still nice to avoid
compiler warnings.

Signed-off-by: Luis de Bethencourt luis...@samsung.com
---
  drivers/media/dvb-frontends/rtl2832.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/rtl2832.c 
b/drivers/media/dvb-frontends/rtl2832.c
index 5d2d8f4..ad36d1c 100644
--- a/drivers/media/dvb-frontends/rtl2832.c
+++ b/drivers/media/dvb-frontends/rtl2832.c
@@ -685,7 +685,7 @@ static int rtl2832_read_status(struct dvb_frontend *fe, 
fe_status_t *status)
struct rtl2832_dev *dev = fe-demodulator_priv;
struct i2c_client *client = dev-client;
int ret;
-   u32 tmp;
+   u32 tmp = 0;

dev_dbg(client-dev, \n);


I looked the code and I cannot see how it could used as uninitialized. 
Dunno how it could be fixed properly.


Also, I think idiom to say compiler that variable could be uninitialized 
is to store its own value. But I am fine with zero initialization too.


u32 tmp = tmp;

regards
Antti

--
http://palosaari.fi/
--
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] media:dvb-frontends: Change setting of variable interval to the correct values in the function, hd29l2_get_frontend for the switch statement checking the frame header

[Antti Palosaari]

Yet another bad patch. Do not touch whole driver unless you understand 
and can test your patches!


Antti


On 02/03/2015 05:52 AM, Nicholas Krause wrote:

This changes the switch statement checking the frame header of the pointer,
c as a pointer to a structure of type,dtv_frontend_properties to set the
variable,interval correctly in the switch statement for checking the frame
header as part of this structure pointer,c for this function correctly as
required by the cases in this switch statement.

Signed-off-by: Nicholas Krause 
---
  drivers/media/dvb-frontends/hd29l2.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/hd29l2.c 
b/drivers/media/dvb-frontends/hd29l2.c
index d7b9d54..3d1a013 100644
--- a/drivers/media/dvb-frontends/hd29l2.c
+++ b/drivers/media/dvb-frontends/hd29l2.c
@@ -635,15 +635,15 @@ static int hd29l2_get_frontend(struct dvb_frontend *fe)
switch ((buf[1] >> 0) & 0x03) {
case 0: /* PN945 */
str_guard_interval = "PN945";
-   c->guard_interval = GUARD_INTERVAL_AUTO; /* FIXME */
+   c->guard_interval = GUARD_INTERVAL_PN945;
break;
case 1: /* PN595 */
str_guard_interval = "PN595";
-   c->guard_interval = GUARD_INTERVAL_AUTO; /* FIXME */
+   c->guard_interval = GUARD_INTERVAL_PN595;
break;
case 2: /* PN420 */
str_guard_interval = "PN420";
-   c->guard_interval = GUARD_INTERVAL_AUTO; /* FIXME */
+   c->guard_interval = GUARD_INTERVAL_PN420;
break;
default:
str_guard_interval = "?";



--
http://palosaari.fi/
--
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] media:dvb-frontends: Change setting of variable interval to the correct values in the function, hd29l2_get_frontend for the switch statement checking the frame header

[Antti Palosaari]

Yet another bad patch. Do not touch whole driver unless you understand 
and can test your patches!


Antti


On 02/03/2015 05:52 AM, Nicholas Krause wrote:

This changes the switch statement checking the frame header of the pointer,
c as a pointer to a structure of type,dtv_frontend_properties to set the
variable,interval correctly in the switch statement for checking the frame
header as part of this structure pointer,c for this function correctly as
required by the cases in this switch statement.

Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
  drivers/media/dvb-frontends/hd29l2.c | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/drivers/media/dvb-frontends/hd29l2.c 
b/drivers/media/dvb-frontends/hd29l2.c
index d7b9d54..3d1a013 100644
--- a/drivers/media/dvb-frontends/hd29l2.c
+++ b/drivers/media/dvb-frontends/hd29l2.c
@@ -635,15 +635,15 @@ static int hd29l2_get_frontend(struct dvb_frontend *fe)
switch ((buf[1]  0)  0x03) {
case 0: /* PN945 */
str_guard_interval = PN945;
-   c-guard_interval = GUARD_INTERVAL_AUTO; /* FIXME */
+   c-guard_interval = GUARD_INTERVAL_PN945;
break;
case 1: /* PN595 */
str_guard_interval = PN595;
-   c-guard_interval = GUARD_INTERVAL_AUTO; /* FIXME */
+   c-guard_interval = GUARD_INTERVAL_PN595;
break;
case 2: /* PN420 */
str_guard_interval = PN420;
-   c-guard_interval = GUARD_INTERVAL_AUTO; /* FIXME */
+   c-guard_interval = GUARD_INTERVAL_PN420;
break;
default:
str_guard_interval = ?;



--
http://palosaari.fi/
--
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] media:dvb-frontends:Change setting of dtv_frontend_properties modulation to the correct value in the function,hd29l2_get_frontend

[Antti Palosaari]

Moikka!
That patch is not correct and will not even compile. Problem is that 
QAM_4NR and QAM_4 are not defined (OK, QPSK is QAM-4).


regards
Antti

On 02/02/2015 04:34 PM, Nicholas Krause wrote:

Changes the values in the switch statement of the function,d29l2_get_frontend
to use the proper value for the dtv_frontend_properties modulation value. 
Further
more this changes the values of case 0 and case 1 to use the correct values of
QAM_4NR and QAM_4 respectfully.

Signed-off-by: Nicholas Krause 
---
  drivers/media/dvb-frontends/hd29l2.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/hd29l2.c 
b/drivers/media/dvb-frontends/hd29l2.c
index d7b9d54..48cafc9 100644
--- a/drivers/media/dvb-frontends/hd29l2.c
+++ b/drivers/media/dvb-frontends/hd29l2.c
@@ -579,11 +579,11 @@ static int hd29l2_get_frontend(struct dvb_frontend *fe)
switch ((buf[0] >> 0) & 0x07) {
case 0: /* QAM4NR */
str_constellation = "QAM4NR";
-   c->modulation = QAM_AUTO; /* FIXME */
+   c->modulation = QAM_4NR;
break;
case 1: /* QAM4 */
str_constellation = "QAM4";
-   c->modulation = QPSK; /* FIXME */
+   c->modulation = QAM_4;
break;
case 2:
str_constellation = "QAM16";



--
http://palosaari.fi/
--
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] media:dvb-frontends:Change setting of dtv_frontend_properties modulation to the correct value in the function,hd29l2_get_frontend

[Antti Palosaari]

Moikka!
That patch is not correct and will not even compile. Problem is that 
QAM_4NR and QAM_4 are not defined (OK, QPSK is QAM-4).


regards
Antti

On 02/02/2015 04:34 PM, Nicholas Krause wrote:

Changes the values in the switch statement of the function,d29l2_get_frontend
to use the proper value for the dtv_frontend_properties modulation value. 
Further
more this changes the values of case 0 and case 1 to use the correct values of
QAM_4NR and QAM_4 respectfully.

Signed-off-by: Nicholas Krause xerofo...@gmail.com
---
  drivers/media/dvb-frontends/hd29l2.c | 4 ++--
  1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/media/dvb-frontends/hd29l2.c 
b/drivers/media/dvb-frontends/hd29l2.c
index d7b9d54..48cafc9 100644
--- a/drivers/media/dvb-frontends/hd29l2.c
+++ b/drivers/media/dvb-frontends/hd29l2.c
@@ -579,11 +579,11 @@ static int hd29l2_get_frontend(struct dvb_frontend *fe)
switch ((buf[0]  0)  0x07) {
case 0: /* QAM4NR */
str_constellation = QAM4NR;
-   c-modulation = QAM_AUTO; /* FIXME */
+   c-modulation = QAM_4NR;
break;
case 1: /* QAM4 */
str_constellation = QAM4;
-   c-modulation = QPSK; /* FIXME */
+   c-modulation = QAM_4;
break;
case 2:
str_constellation = QAM16;



--
http://palosaari.fi/
--
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] Fixed all coding style issues for drivers/staging/media/lirc/

[Antti Palosaari]

On 10/02/2014 07:45 PM, Joe Perches wrote:

On Thu, 2014-10-02 at 10:29 -0300, Mauro Carvalho Chehab wrote:

Em Wed, 01 Oct 2014 21:40:02 -0700 Amber Thrall  
escreveu:

Fixed various coding style issues, including strings over 80 characters long 
and many
deprecated printk's have been replaced with proper methods.

[]

diff --git a/drivers/staging/media/lirc/lirc_imon.c 
b/drivers/staging/media/lirc/lirc_imon.c

[]

@@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context 
*context,
if (debug) {
dev_info(dev, "raw packet: ");
for (i = 0; i < len; ++i)
-   printk("%02x ", buf[i]);
-   printk("\n");
+   dev_info(dev, "%02x ", buf[i]);
+   dev_info(dev, "\n");
}


This is wrong, as the second printk should be printk_cont.

The best here would be to change all above to use %*ph.
So, just:

dev_debug(dev, "raw packet: %*ph\n", len, buf);


Not quite.

%*ph is length limited and only useful for lengths < 30 or so.
Even then, it's pretty ugly.

print_hex_dump_debug() is generally better.


That is place where you print 8 debug bytes, which are received remote 
controller code. IMHO %*ph format is just what you like in that case.


Why print_hex_dump_debug() is better? IIRC it could not be even 
controlled like those dynamic debug printings.


regards
Antti

--
http://palosaari.fi/
--
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] Fixed all coding style issues for drivers/staging/media/lirc/

[Antti Palosaari]

On 10/02/2014 07:45 PM, Joe Perches wrote:

On Thu, 2014-10-02 at 10:29 -0300, Mauro Carvalho Chehab wrote:

Em Wed, 01 Oct 2014 21:40:02 -0700 Amber Thrall amber.rose.thr...@gmail.com 
escreveu:

Fixed various coding style issues, including strings over 80 characters long 
and many
deprecated printk's have been replaced with proper methods.

[]

diff --git a/drivers/staging/media/lirc/lirc_imon.c 
b/drivers/staging/media/lirc/lirc_imon.c

[]

@@ -623,8 +623,8 @@ static void imon_incoming_packet(struct imon_context 
*context,
if (debug) {
dev_info(dev, raw packet: );
for (i = 0; i  len; ++i)
-   printk(%02x , buf[i]);
-   printk(\n);
+   dev_info(dev, %02x , buf[i]);
+   dev_info(dev, \n);
}


This is wrong, as the second printk should be printk_cont.

The best here would be to change all above to use %*ph.
So, just:

dev_debug(dev, raw packet: %*ph\n, len, buf);


Not quite.

%*ph is length limited and only useful for lengths  30 or so.
Even then, it's pretty ugly.

print_hex_dump_debug() is generally better.


That is place where you print 8 debug bytes, which are received remote 
controller code. IMHO %*ph format is just what you like in that case.


Why print_hex_dump_debug() is better? IIRC it could not be even 
controlled like those dynamic debug printings.


regards
Antti

--
http://palosaari.fi/
--
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: [media/dvb_usb_af9005] BUG: unable to handle kernel paging request (WAS: [media/em28xx] BUG: unable to handle kernel)

[Antti Palosaari]

Moikka!

On 09/19/2014 10:55 PM, Luca Olivetti wrote:

El 19/09/14 21:22, Frank Schäfer ha escrit:



So symbol_request() returns pointers.!= NULL

A closer look at the definition of symbol_request() shows, that it does
nothing if CONFIG_MODULES is disabled (it just returns its argument).


One possibility to fix this bug would be to embrace these three lines with

#ifdef CONFIG_DVB_USB_AF9005_REMOTE
...
#endif

Luca, what do you think ?

This seems to be an ancient bug, which is known at least since 5 1/2 years:
https://lkml.org/lkml/2009/2/4/350


Well, it's been a while so I don't remember the details, but I think the
same now as then ;-)
The idea behind CONFIG_DVB_USB_AF9005_REMOTE was to provide an
alternative implementation (based on lirc, at the time it wasn't in the
kernel), since this adapter doesn't decode the IR pulses by itself.
In theory you could leave it undefined but still provide an
implementation in a different module. Just adding

#ifdef CONFIG_DVB_USB_AF9005_REMOTE

would nuke the (futile?) effort.

Now, since the problem seems to be with CONFIG_MODULES disabled, maybe
you could combine both conditions

#if defined(CONFIG_MODULE) || defined(CONFIG_DVB_USB_AF9005_REMOTE)


Proper fix is to remove whole home made IR decider and use common IR 
decoders in kernel nowadays... And yes, that is very old driver and at 
the time Luca made it there was no IR decoders nor whole remote 
controller framework.


regards
Antti

--
http://palosaari.fi/
--
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: [media/dvb_usb_af9005] BUG: unable to handle kernel paging request (WAS: [media/em28xx] BUG: unable to handle kernel)

[Antti Palosaari]

Moikka!

On 09/19/2014 10:55 PM, Luca Olivetti wrote:

El 19/09/14 21:22, Frank Schäfer ha escrit:



So symbol_request() returns pointers.!= NULL

A closer look at the definition of symbol_request() shows, that it does
nothing if CONFIG_MODULES is disabled (it just returns its argument).


One possibility to fix this bug would be to embrace these three lines with

#ifdef CONFIG_DVB_USB_AF9005_REMOTE
...
#endif

Luca, what do you think ?

This seems to be an ancient bug, which is known at least since 5 1/2 years:
https://lkml.org/lkml/2009/2/4/350


Well, it's been a while so I don't remember the details, but I think the
same now as then ;-)
The idea behind CONFIG_DVB_USB_AF9005_REMOTE was to provide an
alternative implementation (based on lirc, at the time it wasn't in the
kernel), since this adapter doesn't decode the IR pulses by itself.
In theory you could leave it undefined but still provide an
implementation in a different module. Just adding

#ifdef CONFIG_DVB_USB_AF9005_REMOTE

would nuke the (futile?) effort.

Now, since the problem seems to be with CONFIG_MODULES disabled, maybe
you could combine both conditions

#if defined(CONFIG_MODULE) || defined(CONFIG_DVB_USB_AF9005_REMOTE)


Proper fix is to remove whole home made IR decider and use common IR 
decoders in kernel nowadays... And yes, that is very old driver and at 
the time Luca made it there was no IR decoders nor whole remote 
controller framework.


regards
Antti

--
http://palosaari.fi/
--
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] Kconfig: do not select SPI bus on sub-driver auto-select

[Antti Palosaari]

We should not select SPI bus when sub-driver auto-select is
selected. That option is meant for auto-selecting all possible
ancillary drivers used for selected board driver. Ancillary
drivers should define needed dependencies itself.

I2C and I2C_MUX are still selected here for a reason described on
commit 347f7a3763601d7b466898d1f10080b7083ac4a3

Reverts commit e4462ffc1602d9df21c00a0381dca9080474e27a

Reported-by: Jeff Mahoney 
Signed-off-by: Antti Palosaari 
---
 drivers/media/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index f60bad4..3c89fcb 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -182,7 +182,6 @@ config MEDIA_SUBDRV_AUTOSELECT
depends on HAS_IOMEM
select I2C
select I2C_MUX
-   select SPI
default y
help
  By default, a media driver auto-selects all possible ancillary
-- 
http://palosaari.fi/

--
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: Autoselecting SPI for MEDIA_SUBDRV_AUTOSELECT?

[Antti Palosaari]

On 08/22/2014 06:24 PM, Jeff Mahoney wrote:

On Fri Aug 22 11:17:22 2014, Antti Palosaari wrote:

Moikka!

On 08/22/2014 06:00 PM, Jeff Mahoney wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Antti -

Commit e4462ffc160 ([media] Kconfig: sub-driver auto-select SPI bus)
enables CONFIG_SPI globally for a driver that won't even be enabled in
many cases.

Is there a reason USB_MSI2500 doesn't select SPI instead of
MEDIA_SUBDRV_AUTOSELECT?


Nothing but I decided to set it similarly as I2C, another more common
bus. IIRC same was for I2C_MUX too.

You could still disable media subdriver autoselect and then disable
SPI and select all the media drivers (excluding MSSi2500) manually.

I have feeling that media auto-select was added to select everything
needed for media.


Ok, that makes sense. I suppose I'll still need to enable SPI just for
this device and disable every other SPI device anyway. I'll live.


See drivers/media/Kconfig :

config MEDIA_SUBDRV_AUTOSELECT
bool "Autoselect ancillary drivers (tuners, sensors, i2c, frontends)"
	depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || 
MEDIA_CAMERA_SUPPORT || MEDIA_SDR_SUPPORT

depends on HAS_IOMEM
select I2C
select I2C_MUX
select SPI
default y
help
  By default, a media driver auto-selects all possible ancillary
  devices such as tuners, sensors, video encoders/decoders and
  frontends, that are used by any of the supported devices.

  This is generally the right thing to do, except when there
  are strict constraints with regards to the kernel size,
  like on embedded systems.

  Use this option with care, as deselecting ancillary drivers which
  are, in fact, necessary will result in the lack of the needed
  functionality for your device (it may not tune or may not have
  the needed demodulators).

  If unsure say Y.


regards
Antti

--
http://palosaari.fi/
--
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: Autoselecting SPI for MEDIA_SUBDRV_AUTOSELECT?

[Antti Palosaari]

Moikka!

On 08/22/2014 06:00 PM, Jeff Mahoney wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Antti -

Commit e4462ffc160 ([media] Kconfig: sub-driver auto-select SPI bus)
enables CONFIG_SPI globally for a driver that won't even be enabled in
many cases.

Is there a reason USB_MSI2500 doesn't select SPI instead of
MEDIA_SUBDRV_AUTOSELECT?


Nothing but I decided to set it similarly as I2C, another more common 
bus. IIRC same was for I2C_MUX too.


You could still disable media subdriver autoselect and then disable SPI 
and select all the media drivers (excluding MSSi2500) manually.


I have feeling that media auto-select was added to select everything 
needed for media.


regards
Antti

--
http://palosaari.fi/
--
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: Autoselecting SPI for MEDIA_SUBDRV_AUTOSELECT?

[Antti Palosaari]

Moikka!

On 08/22/2014 06:00 PM, Jeff Mahoney wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Antti -

Commit e4462ffc160 ([media] Kconfig: sub-driver auto-select SPI bus)
enables CONFIG_SPI globally for a driver that won't even be enabled in
many cases.

Is there a reason USB_MSI2500 doesn't select SPI instead of
MEDIA_SUBDRV_AUTOSELECT?


Nothing but I decided to set it similarly as I2C, another more common 
bus. IIRC same was for I2C_MUX too.


You could still disable media subdriver autoselect and then disable SPI 
and select all the media drivers (excluding MSSi2500) manually.


I have feeling that media auto-select was added to select everything 
needed for media.


regards
Antti

--
http://palosaari.fi/
--
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: Autoselecting SPI for MEDIA_SUBDRV_AUTOSELECT?

[Antti Palosaari]

On 08/22/2014 06:24 PM, Jeff Mahoney wrote:

On Fri Aug 22 11:17:22 2014, Antti Palosaari wrote:

Moikka!

On 08/22/2014 06:00 PM, Jeff Mahoney wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Antti -

Commit e4462ffc160 ([media] Kconfig: sub-driver auto-select SPI bus)
enables CONFIG_SPI globally for a driver that won't even be enabled in
many cases.

Is there a reason USB_MSI2500 doesn't select SPI instead of
MEDIA_SUBDRV_AUTOSELECT?


Nothing but I decided to set it similarly as I2C, another more common
bus. IIRC same was for I2C_MUX too.

You could still disable media subdriver autoselect and then disable
SPI and select all the media drivers (excluding MSSi2500) manually.

I have feeling that media auto-select was added to select everything
needed for media.


Ok, that makes sense. I suppose I'll still need to enable SPI just for
this device and disable every other SPI device anyway. I'll live.


See drivers/media/Kconfig :

config MEDIA_SUBDRV_AUTOSELECT
bool Autoselect ancillary drivers (tuners, sensors, i2c, frontends)
	depends on MEDIA_ANALOG_TV_SUPPORT || MEDIA_DIGITAL_TV_SUPPORT || 
MEDIA_CAMERA_SUPPORT || MEDIA_SDR_SUPPORT

depends on HAS_IOMEM
select I2C
select I2C_MUX
select SPI
default y
help
  By default, a media driver auto-selects all possible ancillary
  devices such as tuners, sensors, video encoders/decoders and
  frontends, that are used by any of the supported devices.

  This is generally the right thing to do, except when there
  are strict constraints with regards to the kernel size,
  like on embedded systems.

  Use this option with care, as deselecting ancillary drivers which
  are, in fact, necessary will result in the lack of the needed
  functionality for your device (it may not tune or may not have
  the needed demodulators).

  If unsure say Y.


regards
Antti

--
http://palosaari.fi/
--
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] Kconfig: do not select SPI bus on sub-driver auto-select

[Antti Palosaari]

We should not select SPI bus when sub-driver auto-select is
selected. That option is meant for auto-selecting all possible
ancillary drivers used for selected board driver. Ancillary
drivers should define needed dependencies itself.

I2C and I2C_MUX are still selected here for a reason described on
commit 347f7a3763601d7b466898d1f10080b7083ac4a3

Reverts commit e4462ffc1602d9df21c00a0381dca9080474e27a

Reported-by: Jeff Mahoney je...@suse.com
Signed-off-by: Antti Palosaari cr...@iki.fi
---
 drivers/media/Kconfig | 1 -
 1 file changed, 1 deletion(-)

diff --git a/drivers/media/Kconfig b/drivers/media/Kconfig
index f60bad4..3c89fcb 100644
--- a/drivers/media/Kconfig
+++ b/drivers/media/Kconfig
@@ -182,7 +182,6 @@ config MEDIA_SUBDRV_AUTOSELECT
depends on HAS_IOMEM
select I2C
select I2C_MUX
-   select SPI
default y
help
  By default, a media driver auto-selects all possible ancillary
-- 
http://palosaari.fi/

--
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] media: em28xx-dvb unregister i2c tuner and demod after fe detach

[Antti Palosaari]

Moikka!

On 07/15/2014 08:29 PM, Shuah Khan wrote:

On 07/12/2014 02:14 PM, Antti Palosaari wrote:

Moikka Shuah!
I suspect that patch makes no sense. On DVB there is runtime PM
controlled by DVB frontend. It wakes up all FE sub-devices when frontend
device is opened and sleeps when closed.

FE release() is not relevant at all for those sub-devices which are
implemented as a proper I2C client. I2C client has own remove() for that.

em28xx_dvb_init and em28xx_dvb_fini are counterparts. Those I2C drivers
are load on em28xx_dvb_init so logical place for unload is
em28xx_dvb_fini.

Is there some real use case you need that change?

regards
Antti



Hi Antti,

The reason I made this change is because dvb_frontend_detach()
calls release interfaces for fe as well as tuner. So it made
sense to move the remove after that is all done. Are you saying
fe and tuner release calls aren't relevant when sub-devices
implement a proper i2c client? If that is the case then, and
there is no chance for these release calls to be invoked when a
proper i2c is present, then my patch isn't needed.


Yes, that is just case. Proprietary DVB binding model uses attach / 
release, but I2C binding model has probe / remove. I see no reason use 
DVB proprietary model, instead drivers should be converted to kernel I2C 
model.


regards
Antti

--
http://palosaari.fi/
--
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] media: em28xx-dvb unregister i2c tuner and demod after fe detach

[Antti Palosaari]

Moikka!

On 07/15/2014 08:29 PM, Shuah Khan wrote:

On 07/12/2014 02:14 PM, Antti Palosaari wrote:

Moikka Shuah!
I suspect that patch makes no sense. On DVB there is runtime PM
controlled by DVB frontend. It wakes up all FE sub-devices when frontend
device is opened and sleeps when closed.

FE release() is not relevant at all for those sub-devices which are
implemented as a proper I2C client. I2C client has own remove() for that.

em28xx_dvb_init and em28xx_dvb_fini are counterparts. Those I2C drivers
are load on em28xx_dvb_init so logical place for unload is
em28xx_dvb_fini.

Is there some real use case you need that change?

regards
Antti



Hi Antti,

The reason I made this change is because dvb_frontend_detach()
calls release interfaces for fe as well as tuner. So it made
sense to move the remove after that is all done. Are you saying
fe and tuner release calls aren't relevant when sub-devices
implement a proper i2c client? If that is the case then, and
there is no chance for these release calls to be invoked when a
proper i2c is present, then my patch isn't needed.


Yes, that is just case. Proprietary DVB binding model uses attach / 
release, but I2C binding model has probe / remove. I see no reason use 
DVB proprietary model, instead drivers should be converted to kernel I2C 
model.


regards
Antti

--
http://palosaari.fi/
--
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] media: em28xx-dvb - fix em28xx_dvb_resume() to not unregister i2c and dvb

[Antti Palosaari]

Reviewed-by: Antti Palosaari 

Antti

On 07/09/2014 04:21 PM, Shuah Khan wrote:

em28xx_dvb_resume() unregisters i2c tuner, i2c demod, and dvb.
This erroneous cleanup results in i2c tuner, i2c demod, and dvb
devices unregistered and removed during resume. This error is a
result of merge conflict between two patches that went into 3.15.

Signed-off-by: Shuah Khan 
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   17 -
  1 file changed, 17 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a121ed9..d381861 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1712,7 +1712,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
em28xx_info("Resuming DVB extension");
if (dev->dvb) {
struct em28xx_dvb *dvb = dev->dvb;
-   struct i2c_client *client = dvb->i2c_client_tuner;

if (dvb->fe[0]) {
ret = dvb_frontend_resume(dvb->fe[0]);
@@ -1723,22 +1722,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
ret = dvb_frontend_resume(dvb->fe[1]);
em28xx_info("fe1 resume %d", ret);
}
-   /* remove I2C tuner */
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
-   /* remove I2C demod */
-   client = dvb->i2c_client_demod;
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
-   em28xx_unregister_dvb(dvb);
-   kfree(dvb);
-   dev->dvb = NULL;
}

return 0;



--
http://palosaari.fi/
--
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] media: em28xx - add error handling for KWORLD dvb_attach failures

[Antti Palosaari]

Looks correct!
All the other devices, excluding those few PCTV ones I have added, has 
that same bug... Deadlocks if tuner attach fails.


Reviewed-by: Antti Palosaari 

regards
Antti


On 07/09/2014 11:36 PM, Shuah Khan wrote:

Add error hanlding when EM2870_BOARD_KWORLD_A340 dvb_attach()
for fe and tuner fail in em28xx_dvb_init().

Signed-off-by: Shuah Khan 
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index d381861..8314f51 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1213,9 +1213,17 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb->fe[0] = dvb_attach(lgdt3305_attach,
   _lgdt3304_dev,
   >i2c_adap[dev->def_i2c_bus]);
-   if (dvb->fe[0] != NULL)
-   dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
-  >i2c_adap[dev->def_i2c_bus], 
_a340_config);
+   if (!dvb->fe[0]) {
+   result = -EINVAL;
+   goto out_free;
+   }
+   if (!dvb_attach(tda18271_attach, dvb->fe[0], 0x60,
+   >i2c_adap[dev->def_i2c_bus],
+   _a340_config)) {
+   dvb_frontend_detach(dvb->fe[0]);
+   result = -EINVAL;
+   goto out_free;
+   }
break;
case EM28174_BOARD_PCTV_290E:
/* set default GPIO0 for LNA, used if GPIOLIB is undefined */



--
http://palosaari.fi/
--
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] media: em28xx-dvb unregister i2c tuner and demod after fe detach

[Antti Palosaari]

Moikka Shuah!
I suspect that patch makes no sense. On DVB there is runtime PM 
controlled by DVB frontend. It wakes up all FE sub-devices when frontend 
device is opened and sleeps when closed.


FE release() is not relevant at all for those sub-devices which are 
implemented as a proper I2C client. I2C client has own remove() for that.


em28xx_dvb_init and em28xx_dvb_fini are counterparts. Those I2C drivers 
are load on em28xx_dvb_init so logical place for unload is em28xx_dvb_fini.


Is there some real use case you need that change?

regards
Antti


On 07/11/2014 06:45 PM, Shuah Khan wrote:

i2c tuner and demod are unregisetred in .fini before fe detach.
dvb_unregister_frontend() and dvb_frontend_detach() invoke tuner
sleep() and release() interfaces. Change to unregister i2c tuner
and demod from em28xx_unregister_dvb() after unregistering dvb
and detaching fe.

Signed-off-by: Shuah Khan 
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   32 +---
  1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 8314f51..8d5cb62 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1030,6 +1030,8 @@ fail_adapter:

  static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
  {
+   struct i2c_client *client;
+
dvb_net_release(>net);
dvb->demux.dmx.remove_frontend(>demux.dmx, >fe_mem);
dvb->demux.dmx.remove_frontend(>demux.dmx, >fe_hw);
@@ -1041,6 +1043,21 @@ static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
if (dvb->fe[1] && !dvb->dont_attach_fe1)
dvb_frontend_detach(dvb->fe[1]);
dvb_frontend_detach(dvb->fe[0]);
+
+   /* remove I2C tuner */
+   client = dvb->i2c_client_tuner;
+   if (client) {
+   module_put(client->dev.driver->owner);
+   i2c_unregister_device(client);
+   }
+
+   /* remove I2C demod */
+   client = dvb->i2c_client_demod;
+   if (client) {
+   module_put(client->dev.driver->owner);
+   i2c_unregister_device(client);
+   }
+
dvb_unregister_adapter(>adapter);
  }

@@ -1628,7 +1645,6 @@ static inline void prevent_sleep(struct dvb_frontend_ops 
*ops)
  static int em28xx_dvb_fini(struct em28xx *dev)
  {
struct em28xx_dvb *dvb;
-   struct i2c_client *client;

if (dev->is_audio_only) {
/* Shouldn't initialize IR for this interface */
@@ -1646,7 +1662,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
em28xx_info("Closing DVB extension");

dvb = dev->dvb;
-   client = dvb->i2c_client_tuner;

em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);

@@ -1659,19 +1674,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
prevent_sleep(>fe[1]->ops);
}

-   /* remove I2C tuner */
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
-   /* remove I2C demod */
-   client = dvb->i2c_client_demod;
-   if (client) {
-   module_put(client->dev.driver->owner);
-   i2c_unregister_device(client);
-   }
-
em28xx_unregister_dvb(dvb);
kfree(dvb);
dev->dvb = NULL;



--
http://palosaari.fi/
--
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] media: em28xx-dvb unregister i2c tuner and demod after fe detach

[Antti Palosaari]

Moikka Shuah!
I suspect that patch makes no sense. On DVB there is runtime PM 
controlled by DVB frontend. It wakes up all FE sub-devices when frontend 
device is opened and sleeps when closed.


FE release() is not relevant at all for those sub-devices which are 
implemented as a proper I2C client. I2C client has own remove() for that.


em28xx_dvb_init and em28xx_dvb_fini are counterparts. Those I2C drivers 
are load on em28xx_dvb_init so logical place for unload is em28xx_dvb_fini.


Is there some real use case you need that change?

regards
Antti


On 07/11/2014 06:45 PM, Shuah Khan wrote:

i2c tuner and demod are unregisetred in .fini before fe detach.
dvb_unregister_frontend() and dvb_frontend_detach() invoke tuner
sleep() and release() interfaces. Change to unregister i2c tuner
and demod from em28xx_unregister_dvb() after unregistering dvb
and detaching fe.

Signed-off-by: Shuah Khan shuah...@samsung.com
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   32 +---
  1 file changed, 17 insertions(+), 15 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index 8314f51..8d5cb62 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1030,6 +1030,8 @@ fail_adapter:

  static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
  {
+   struct i2c_client *client;
+
dvb_net_release(dvb-net);
dvb-demux.dmx.remove_frontend(dvb-demux.dmx, dvb-fe_mem);
dvb-demux.dmx.remove_frontend(dvb-demux.dmx, dvb-fe_hw);
@@ -1041,6 +1043,21 @@ static void em28xx_unregister_dvb(struct em28xx_dvb *dvb)
if (dvb-fe[1]  !dvb-dont_attach_fe1)
dvb_frontend_detach(dvb-fe[1]);
dvb_frontend_detach(dvb-fe[0]);
+
+   /* remove I2C tuner */
+   client = dvb-i2c_client_tuner;
+   if (client) {
+   module_put(client-dev.driver-owner);
+   i2c_unregister_device(client);
+   }
+
+   /* remove I2C demod */
+   client = dvb-i2c_client_demod;
+   if (client) {
+   module_put(client-dev.driver-owner);
+   i2c_unregister_device(client);
+   }
+
dvb_unregister_adapter(dvb-adapter);
  }

@@ -1628,7 +1645,6 @@ static inline void prevent_sleep(struct dvb_frontend_ops 
*ops)
  static int em28xx_dvb_fini(struct em28xx *dev)
  {
struct em28xx_dvb *dvb;
-   struct i2c_client *client;

if (dev-is_audio_only) {
/* Shouldn't initialize IR for this interface */
@@ -1646,7 +1662,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
em28xx_info(Closing DVB extension);

dvb = dev-dvb;
-   client = dvb-i2c_client_tuner;

em28xx_uninit_usb_xfer(dev, EM28XX_DIGITAL_MODE);

@@ -1659,19 +1674,6 @@ static int em28xx_dvb_fini(struct em28xx *dev)
prevent_sleep(dvb-fe[1]-ops);
}

-   /* remove I2C tuner */
-   if (client) {
-   module_put(client-dev.driver-owner);
-   i2c_unregister_device(client);
-   }
-
-   /* remove I2C demod */
-   client = dvb-i2c_client_demod;
-   if (client) {
-   module_put(client-dev.driver-owner);
-   i2c_unregister_device(client);
-   }
-
em28xx_unregister_dvb(dvb);
kfree(dvb);
dev-dvb = NULL;



--
http://palosaari.fi/
--
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] media: em28xx - add error handling for KWORLD dvb_attach failures

[Antti Palosaari]

Looks correct!
All the other devices, excluding those few PCTV ones I have added, has 
that same bug... Deadlocks if tuner attach fails.


Reviewed-by: Antti Palosaari cr...@iki.fi

regards
Antti


On 07/09/2014 11:36 PM, Shuah Khan wrote:

Add error hanlding when EM2870_BOARD_KWORLD_A340 dvb_attach()
for fe and tuner fail in em28xx_dvb_init().

Signed-off-by: Shuah Khan shuah...@samsung.com
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   14 +++---
  1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index d381861..8314f51 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1213,9 +1213,17 @@ static int em28xx_dvb_init(struct em28xx *dev)
dvb-fe[0] = dvb_attach(lgdt3305_attach,
   em2870_lgdt3304_dev,
   dev-i2c_adap[dev-def_i2c_bus]);
-   if (dvb-fe[0] != NULL)
-   dvb_attach(tda18271_attach, dvb-fe[0], 0x60,
-  dev-i2c_adap[dev-def_i2c_bus], 
kworld_a340_config);
+   if (!dvb-fe[0]) {
+   result = -EINVAL;
+   goto out_free;
+   }
+   if (!dvb_attach(tda18271_attach, dvb-fe[0], 0x60,
+   dev-i2c_adap[dev-def_i2c_bus],
+   kworld_a340_config)) {
+   dvb_frontend_detach(dvb-fe[0]);
+   result = -EINVAL;
+   goto out_free;
+   }
break;
case EM28174_BOARD_PCTV_290E:
/* set default GPIO0 for LNA, used if GPIOLIB is undefined */



--
http://palosaari.fi/
--
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] media: em28xx-dvb - fix em28xx_dvb_resume() to not unregister i2c and dvb

[Antti Palosaari]

Reviewed-by: Antti Palosaari cr...@iki.fi

Antti

On 07/09/2014 04:21 PM, Shuah Khan wrote:

em28xx_dvb_resume() unregisters i2c tuner, i2c demod, and dvb.
This erroneous cleanup results in i2c tuner, i2c demod, and dvb
devices unregistered and removed during resume. This error is a
result of merge conflict between two patches that went into 3.15.

Signed-off-by: Shuah Khan shuah...@samsung.com
---
  drivers/media/usb/em28xx/em28xx-dvb.c |   17 -
  1 file changed, 17 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-dvb.c 
b/drivers/media/usb/em28xx/em28xx-dvb.c
index a121ed9..d381861 100644
--- a/drivers/media/usb/em28xx/em28xx-dvb.c
+++ b/drivers/media/usb/em28xx/em28xx-dvb.c
@@ -1712,7 +1712,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
em28xx_info(Resuming DVB extension);
if (dev-dvb) {
struct em28xx_dvb *dvb = dev-dvb;
-   struct i2c_client *client = dvb-i2c_client_tuner;

if (dvb-fe[0]) {
ret = dvb_frontend_resume(dvb-fe[0]);
@@ -1723,22 +1722,6 @@ static int em28xx_dvb_resume(struct em28xx *dev)
ret = dvb_frontend_resume(dvb-fe[1]);
em28xx_info(fe1 resume %d, ret);
}
-   /* remove I2C tuner */
-   if (client) {
-   module_put(client-dev.driver-owner);
-   i2c_unregister_device(client);
-   }
-
-   /* remove I2C demod */
-   client = dvb-i2c_client_demod;
-   if (client) {
-   module_put(client-dev.driver-owner);
-   i2c_unregister_device(client);
-   }
-
-   em28xx_unregister_dvb(dvb);
-   kfree(dvb);
-   dev-dvb = NULL;
}

return 0;



--
http://palosaari.fi/
--
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 1/1] dvb-frontends: remove unnecessary break after goto

[Antti Palosaari]

Moikka Fabian!
I have no reason to decline that patch (I will apply it) even it has 
hardly meaning. But is there now some new tool which warns that kind of 
issues?


regards
Atnti


On 07/08/2014 08:23 PM, Fabian Frederick wrote:

Cc: Antti Palosaari 
Cc: Mauro Carvalho Chehab 
Cc: linux-me...@vger.kernel.org
Signed-off-by: Fabian Frederick 
---
  drivers/media/dvb-frontends/af9013.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/af9013.c 
b/drivers/media/dvb-frontends/af9013.c
index fb504f1..ecf6388 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -470,7 +470,6 @@ static int af9013_statistics_snr_result(struct dvb_frontend 
*fe)
break;
default:
goto err;
-   break;
}

for (i = 0; i < len; i++) {



--
http://palosaari.fi/
--
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 1/1] dvb-frontends: remove unnecessary break after goto

[Antti Palosaari]

Moikka Fabian!
I have no reason to decline that patch (I will apply it) even it has 
hardly meaning. But is there now some new tool which warns that kind of 
issues?


regards
Atnti


On 07/08/2014 08:23 PM, Fabian Frederick wrote:

Cc: Antti Palosaari cr...@iki.fi
Cc: Mauro Carvalho Chehab m.che...@samsung.com
Cc: linux-me...@vger.kernel.org
Signed-off-by: Fabian Frederick f...@skynet.be
---
  drivers/media/dvb-frontends/af9013.c | 1 -
  1 file changed, 1 deletion(-)

diff --git a/drivers/media/dvb-frontends/af9013.c 
b/drivers/media/dvb-frontends/af9013.c
index fb504f1..ecf6388 100644
--- a/drivers/media/dvb-frontends/af9013.c
+++ b/drivers/media/dvb-frontends/af9013.c
@@ -470,7 +470,6 @@ static int af9013_statistics_snr_result(struct dvb_frontend 
*fe)
break;
default:
goto err;
-   break;
}

for (i = 0; i  len; i++) {



--
http://palosaari.fi/
--
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 1/1] staging: media: msi3101: sdr-msi3101.c - replace with time_before_eq()

[Antti Palosaari]

Moikka!
That is already fixed by someone else and patch is somewhere Mauro or 
Hans queue.


regards
Antti

On 06/29/2014 08:20 AM, Anil Belur wrote:

From: Anil Belur 

- this fix replaces jiffies interval comparision with safer function to
   avoid any overflow and wrap around ?

Signed-off-by: Anil Belur 
---
  drivers/staging/media/msi3101/sdr-msi3101.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c 
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 08d0d09..b828857 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -180,6 +180,7 @@ static int msi3101_convert_stream_504(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -208,7 +209,8 @@ static int msi3101_convert_stream_504(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -332,6 +334,7 @@ static int msi3101_convert_stream_384(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -360,7 +363,8 @@ static int msi3101_convert_stream_384(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -397,6 +401,7 @@ static int msi3101_convert_stream_336(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -425,7 +430,8 @@ static int msi3101_convert_stream_336(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -460,6 +466,7 @@ static int msi3101_convert_stream_252(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -488,7 +495,8 @@ static int msi3101_convert_stream_252(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   expires = s->jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;



--
http://palosaari.fi/
--
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 1/1] staging: media: msi3101: sdr-msi3101.c - replace with time_before_eq()

[Antti Palosaari]

Moikka!
That is already fixed by someone else and patch is somewhere Mauro or 
Hans queue.


regards
Antti

On 06/29/2014 08:20 AM, Anil Belur wrote:

From: Anil Belur ask...@gmail.com

- this fix replaces jiffies interval comparision with safer function to
   avoid any overflow and wrap around ?

Signed-off-by: Anil Belur ask...@gmail.com
---
  drivers/staging/media/msi3101/sdr-msi3101.c | 16 
  1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c 
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 08d0d09..b828857 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -180,6 +180,7 @@ static int msi3101_convert_stream_504(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -208,7 +209,8 @@ static int msi3101_convert_stream_504(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   expires = s-jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
@@ -332,6 +334,7 @@ static int msi3101_convert_stream_384(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -360,7 +363,8 @@ static int msi3101_convert_stream_384(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   expires = s-jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
@@ -397,6 +401,7 @@ static int msi3101_convert_stream_336(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -425,7 +430,8 @@ static int msi3101_convert_stream_336(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   expires = s-jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
@@ -460,6 +466,7 @@ static int msi3101_convert_stream_252(struct msi3101_state 
*s, u8 *dst,
  {
int i, i_max, dst_len = 0;
u32 sample_num[3];
+   unsigned long expires;

/* There could be 1-3 1024 bytes URB frames */
i_max = src_len / 1024;
@@ -488,7 +495,8 @@ static int msi3101_convert_stream_252(struct msi3101_state 
*s, u8 *dst,
}

/* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   expires = s-jiffies_next + msecs_to_jiffies(1);
+   if (time_before_eq(expires, jiffies)) {
unsigned long jiffies_now = jiffies;
unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;



--
http://palosaari.fi/
--
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] msi3103: Use time_before_eq()

[Antti Palosaari]

Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 

Mauro, pick that from patchwork to 3.16. I am not going to PULL request it.

regards
Antti


On 05/25/2014 03:39 PM, Manuel Schölling wrote:

To be future-proof and for better readability the time comparisons are
modified to use time_before_eq() instead of plain, error-prone math.

Signed-off-by: Manuel Schölling 
---
  drivers/staging/media/msi3101/sdr-msi3101.c |   28 +--
  1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c 
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 65d351f..7a0a8ca 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -207,10 +207,10 @@ static int msi3101_convert_stream_504(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
s->jiffies_next = jiffies_now;
s->sample = sample_num[i_max - 1];
@@ -265,7 +265,7 @@ static int msi3101_convert_stream_504_u8(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
+   /* calculate sampling rate and output it in 10 seconds intervals */
if (unlikely(time_is_before_jiffies(s->jiffies_next))) {
  #define MSECS 1UL
unsigned int samples = sample_num[i_max - 1] - s->sample;
@@ -359,10 +359,10 @@ static int msi3101_convert_stream_384(struct 
msi3101_state *s, u8 *dst,
dst_len += 984;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
s->jiffies_next = jiffies_now;
s->sample = sample_num[i_max - 1];
@@ -424,10 +424,10 @@ static int msi3101_convert_stream_336(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
s->jiffies_next = jiffies_now;
s->sample = sample_num[i_max - 1];
@@ -487,10 +487,10 @@ static int msi3101_convert_stream_252(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s->jiffies_next + msecs_to_jiffies(1)) <= jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s->jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s->jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s->jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s->sample;
s->jiffies_next = jiffies_now;
s->sample = sample_num[i_max - 1];
@@ -560,7 +560,7 @@ static int msi3101_convert_stream_252_u16(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
+   /* calculate sampling rate and output it in 10 seconds intervals */
if (unlikely(ti

Re: [PATCH] msi3103: Use time_before_eq()

[Antti Palosaari]

Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi

Mauro, pick that from patchwork to 3.16. I am not going to PULL request it.

regards
Antti


On 05/25/2014 03:39 PM, Manuel Schölling wrote:

To be future-proof and for better readability the time comparisons are
modified to use time_before_eq() instead of plain, error-prone math.

Signed-off-by: Manuel Schölling manuel.schoell...@gmx.de
---
  drivers/staging/media/msi3101/sdr-msi3101.c |   28 +--
  1 file changed, 14 insertions(+), 14 deletions(-)

diff --git a/drivers/staging/media/msi3101/sdr-msi3101.c 
b/drivers/staging/media/msi3101/sdr-msi3101.c
index 65d351f..7a0a8ca 100644
--- a/drivers/staging/media/msi3101/sdr-msi3101.c
+++ b/drivers/staging/media/msi3101/sdr-msi3101.c
@@ -207,10 +207,10 @@ static int msi3101_convert_stream_504(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s-jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
s-jiffies_next = jiffies_now;
s-sample = sample_num[i_max - 1];
@@ -265,7 +265,7 @@ static int msi3101_convert_stream_504_u8(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
+   /* calculate sampling rate and output it in 10 seconds intervals */
if (unlikely(time_is_before_jiffies(s-jiffies_next))) {
  #define MSECS 1UL
unsigned int samples = sample_num[i_max - 1] - s-sample;
@@ -359,10 +359,10 @@ static int msi3101_convert_stream_384(struct 
msi3101_state *s, u8 *dst,
dst_len += 984;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s-jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
s-jiffies_next = jiffies_now;
s-sample = sample_num[i_max - 1];
@@ -424,10 +424,10 @@ static int msi3101_convert_stream_336(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s-jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
s-jiffies_next = jiffies_now;
s-sample = sample_num[i_max - 1];
@@ -487,10 +487,10 @@ static int msi3101_convert_stream_252(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
-   if ((s-jiffies_next + msecs_to_jiffies(1)) = jiffies) {
+   /* calculate sampling rate and output it in 10 seconds intervals */
+   if (time_before_eq(s-jiffies_next + 10 * HZ, jiffies)) {
unsigned long jiffies_now = jiffies;
-   unsigned long msecs = jiffies_to_msecs(jiffies_now) - 
jiffies_to_msecs(s-jiffies_next);
+   unsigned long msecs = jiffies_to_msecs(jiffies_now - 
s-jiffies_next);
unsigned int samples = sample_num[i_max - 1] - s-sample;
s-jiffies_next = jiffies_now;
s-sample = sample_num[i_max - 1];
@@ -560,7 +560,7 @@ static int msi3101_convert_stream_252_u16(struct 
msi3101_state *s, u8 *dst,
dst_len += 1008;
}

-   /* calculate samping rate and output it in 10 seconds intervals */
+   /* calculate sampling rate and output it in 10 seconds intervals */
if (unlikely(time_is_before_jiffies(s-jiffies_next))) {
  #define MSECS 1UL
unsigned

Re: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()

[Antti Palosaari]

On 05/17/2014 07:05 PM, Martin Kepplinger wrote:

don't reinvent dev_dbg(). remove dprintk() in as102_drv.c.
use the common kernel coding style.

Signed-off-by: Martin Kepplinger 


Reviewed-by: Antti Palosaari 


---
this applies to next-20140516. any more suggestions?
more cleanup can be done when dprintk() is completely gone.


Do you have the device? I am a bit reluctant patching that driver 
without any testing as it has happened too many times something has gone 
totally broken.


IIRC Devin said it is in staging because of style issues and nothing 
more. Is that correct?


regards
Antti

--
http://palosaari.fi/
--
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: media: as102: replace custom dprintk() with dev_dbg()

[Antti Palosaari]

you forget to remove debug parameter itself.

Antti


On 05/17/2014 04:16 PM, Martin Kepplinger wrote:

don't reinvent dev_dbg(). use the common kernel coding style.

Signed-off-by: Martin Kepplinger 
---
this applies to next-20140516.

  drivers/staging/media/as102/as102_drv.c |   11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..99c3ed93 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -74,7 +74,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;

if (as10x_cmd_stop_streaming(bus_adap) < 0)
-   dprintk(debug, "as10x_cmd_stop_streaming failed\n");
+   dev_dbg(>bus_adap.usb_dev->dev,
+   "as10x_cmd_stop_streaming failed\n");

mutex_unlock(>bus_adap.lock);
}
@@ -112,14 +113,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;

if (mutex_lock_interruptible(>bus_adap.lock)) {
-   dprintk(debug, "mutex_lock_interruptible(lock) failed !\n");
+   dev_dbg(>bus_adap.usb_dev->dev,
+   "amutex_lock_interruptible(lock) failed !\n");
return -EBUSY;
}

switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
+   dev_dbg(>bus_adap.usb_dev->dev,
+   "DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n",
index, pid, ret);
break;
case 1:
@@ -131,7 +134,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;

ret = as10x_cmd_add_PID_filter(bus_adap, );
-   dprintk(debug,
+   dev_dbg(>bus_adap.usb_dev->dev,
"ADD_PID_FILTER([%02d -> %02d], 0x%04x) ret = %d\n",
index, filter.idx, filter.pid, ret);
break;




--
http://palosaari.fi/
--
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: media: as102: replace custom dprintk() with dev_dbg()

[Antti Palosaari]

you forget to remove debug parameter itself.

Antti


On 05/17/2014 04:16 PM, Martin Kepplinger wrote:

don't reinvent dev_dbg(). use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de
---
this applies to next-20140516.

  drivers/staging/media/as102/as102_drv.c |   11 +++
  1 file changed, 7 insertions(+), 4 deletions(-)

diff --git a/drivers/staging/media/as102/as102_drv.c 
b/drivers/staging/media/as102/as102_drv.c
index 09d64cd..99c3ed93 100644
--- a/drivers/staging/media/as102/as102_drv.c
+++ b/drivers/staging/media/as102/as102_drv.c
@@ -74,7 +74,8 @@ static void as102_stop_stream(struct as102_dev_t *dev)
return;

if (as10x_cmd_stop_streaming(bus_adap)  0)
-   dprintk(debug, as10x_cmd_stop_streaming failed\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   as10x_cmd_stop_streaming failed\n);

mutex_unlock(dev-bus_adap.lock);
}
@@ -112,14 +113,16 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
int ret = -EFAULT;

if (mutex_lock_interruptible(dev-bus_adap.lock)) {
-   dprintk(debug, mutex_lock_interruptible(lock) failed !\n);
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   amutex_lock_interruptible(lock) failed !\n);
return -EBUSY;
}

switch (onoff) {
case 0:
ret = as10x_cmd_del_PID_filter(bus_adap, (uint16_t) pid);
-   dprintk(debug, DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
+   DEL_PID_FILTER([%02d] 0x%04x) ret = %d\n,
index, pid, ret);
break;
case 1:
@@ -131,7 +134,7 @@ static int as10x_pid_filter(struct as102_dev_t *dev,
filter.pid = pid;

ret = as10x_cmd_add_PID_filter(bus_adap, filter);
-   dprintk(debug,
+   dev_dbg(dev-bus_adap.usb_dev-dev,
ADD_PID_FILTER([%02d - %02d], 0x%04x) ret = %d\n,
index, filter.idx, filter.pid, ret);
break;




--
http://palosaari.fi/
--
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: [PATCHv2] staging: media: as102: replace custom dprintk() with dev_dbg()

[Antti Palosaari]

On 05/17/2014 07:05 PM, Martin Kepplinger wrote:

don't reinvent dev_dbg(). remove dprintk() in as102_drv.c.
use the common kernel coding style.

Signed-off-by: Martin Kepplinger mart...@posteo.de


Reviewed-by: Antti Palosaari cr...@iki.fi


---
this applies to next-20140516. any more suggestions?
more cleanup can be done when dprintk() is completely gone.


Do you have the device? I am a bit reluctant patching that driver 
without any testing as it has happened too many times something has gone 
totally broken.


IIRC Devin said it is in staging because of style issues and nothing 
more. Is that correct?


regards
Antti

--
http://palosaari.fi/
--
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: randconfig build error with next-20140324, in drivers/media/tuners/e4000.c

[Antti Palosaari]

Already fixed
https://patchwork.linuxtv.org/patch/23115/

On 24.03.2014 20:38, Jim Davis wrote:

Building with the attached random configuration file,

warning: (DVB_USB_RTL28XXU) selects MEDIA_TUNER_E4000 which has unmet
direct dependencies ((MEDIA_ANALOG_TV_SUPPORT ||
MEDIA_DIGITAL_TV_SUPPORT || MEDIA_RADIO_SUPPORT) && MEDIA_SUPPORT &&
I2C && VIDEO_V4L2)
warning: (BRIDGE_NF_EBTABLES) selects NETFILTER_XTABLES which has
unmet direct dependencies (NET && INET && NETFILTER)
warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct
dependencies (HAS_IOMEM && OF && (ARM64 || COMPILE_TEST))

drivers/built-in.o: In function `e4000_remove':
e4000.c:(.text+0x30570f): undefined reference to `v4l2_ctrl_handler_free'
drivers/built-in.o: In function `e4000_probe':
e4000.c:(.text+0x306085): undefined reference to `v4l2_ctrl_handler_init_class'
e4000.c:(.text+0x3060ae): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3060e1): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3060fd): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x306126): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x306156): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x306172): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x30619b): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3061cb): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3061e7): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x306210): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x306240): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x30625c): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x306285): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3062a0): undefined reference to `v4l2_ctrl_handler_free'
make: *** [vmlinux] Error 1




--
http://palosaari.fi/
--
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: randconfig build error with next-20140324, in drivers/media/tuners/e4000.c

[Antti Palosaari]

Already fixed
https://patchwork.linuxtv.org/patch/23115/

On 24.03.2014 20:38, Jim Davis wrote:

Building with the attached random configuration file,

warning: (DVB_USB_RTL28XXU) selects MEDIA_TUNER_E4000 which has unmet
direct dependencies ((MEDIA_ANALOG_TV_SUPPORT ||
MEDIA_DIGITAL_TV_SUPPORT || MEDIA_RADIO_SUPPORT)  MEDIA_SUPPORT 
I2C  VIDEO_V4L2)
warning: (BRIDGE_NF_EBTABLES) selects NETFILTER_XTABLES which has
unmet direct dependencies (NET  INET  NETFILTER)
warning: (AHCI_XGENE) selects PHY_XGENE which has unmet direct
dependencies (HAS_IOMEM  OF  (ARM64 || COMPILE_TEST))

drivers/built-in.o: In function `e4000_remove':
e4000.c:(.text+0x30570f): undefined reference to `v4l2_ctrl_handler_free'
drivers/built-in.o: In function `e4000_probe':
e4000.c:(.text+0x306085): undefined reference to `v4l2_ctrl_handler_init_class'
e4000.c:(.text+0x3060ae): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3060e1): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3060fd): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x306126): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x306156): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x306172): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x30619b): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3061cb): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3061e7): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x306210): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x306240): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x30625c): undefined reference to `v4l2_ctrl_auto_cluster'
e4000.c:(.text+0x306285): undefined reference to `v4l2_ctrl_new_std'
e4000.c:(.text+0x3062a0): undefined reference to `v4l2_ctrl_handler_free'
make: *** [vmlinux] Error 1




--
http://palosaari.fi/
--
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 v2 1/2] [media] rtl28xxu: add USB ID for Genius TVGo DVB-T03

[Antti Palosaari]

Applied, thanks!
Antti

On 26.02.2014 20:33, Jan Vcelak wrote:

0458:707f KYE Systems Corp. (Mouse Systems) TVGo DVB-T03 [RTL2832]

The USB dongle uses RTL2832U demodulator and FC0012 tuner.

Signed-off-by: Jan Vcelak 
---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index fda5c64..b9eb662 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1429,6 +1429,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
_props, "Leadtek WinFast DTV Dongle mini", NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_CPYTO_REDI_PC50A,
_props, "Crypto ReDi PC 50 A", NULL) },
+   { DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
+   _props, "Genius TVGo DVB-T03", NULL) },

{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
_props, "Astrometa DVB-T2", NULL) },




--
http://palosaari.fi/
--
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 v2 2/2] [media] rtl28xxu: add chipset version comments into device list

[Antti Palosaari]

Applied, thanks!
Antti

On 26.02.2014 20:33, Jan Vcelak wrote:

Signed-off-by: Jan Vcelak 
---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index b9eb662..ab1deac 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1382,6 +1382,7 @@ static const struct dvb_usb_device_properties 
rtl2832u_props = {
  };

  static const struct usb_device_id rtl28xxu_id_table[] = {
+   /* RTL2831U devices: */
{ DVB_USB_DEVICE(USB_VID_REALTEK, USB_PID_REALTEK_RTL2831U,
_props, "Realtek RTL2831U reference design", NULL) },
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT,
@@ -1389,6 +1390,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT_2,
_props, "Freecom USB2.0 DVB-T", NULL) },

+   /* RTL2832U devices: */
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2832,
_props, "Realtek RTL2832U reference design", NULL) },
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
@@ -1432,6 +1434,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
_props, "Genius TVGo DVB-T03", NULL) },

+   /* RTL2832P devices: */
{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
_props, "Astrometa DVB-T2", NULL) },
{ }




--
http://palosaari.fi/
--
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] [media] rtl28xxu: add USB ID for Genius TVGo DVB-T03

[Antti Palosaari]

Thank for the patch.

Even I didn't added any comment to driver ID list, which apparently 
should be there, that empty line before "Astrometa DVB-T2" entry was 
there because I wanted to separate RTL2832P entries from RTL2832U 
entries (different chipset version). So if possible, could you provide a 
new patch which adds that entry after the last RTL2832U device :) Maybe 
some comment like "RTL2832P" could be nice too... I hope this is not too 
much work for you, my mistake...


regards
Antti


On 26.02.2014 02:30, Jan Vcelak wrote:

0458:707f KYE Systems Corp. (Mouse Systems) TVGo DVB-T03 [RTL2832]

The USB dongle uses RTL2832U demodulator and FC0012 tuner.

Signed-off-by: Jan Vcelak 
---

The patch adds support for the Genius TVGo DVB-T03 USB dongle.

  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index fda5c64..bb051c9 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1432,6 +1432,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {

{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
_props, "Astrometa DVB-T2", NULL) },
+   { DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
+   _props, "Genius TVGo DVB-T03", NULL) },
{ }
  };
  MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);




--
http://palosaari.fi/
--
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] [media] rtl28xxu: add USB ID for Genius TVGo DVB-T03

[Antti Palosaari]

Thank for the patch.

Even I didn't added any comment to driver ID list, which apparently 
should be there, that empty line before Astrometa DVB-T2 entry was 
there because I wanted to separate RTL2832P entries from RTL2832U 
entries (different chipset version). So if possible, could you provide a 
new patch which adds that entry after the last RTL2832U device :) Maybe 
some comment like RTL2832P could be nice too... I hope this is not too 
much work for you, my mistake...


regards
Antti


On 26.02.2014 02:30, Jan Vcelak wrote:

0458:707f KYE Systems Corp. (Mouse Systems) TVGo DVB-T03 [RTL2832]

The USB dongle uses RTL2832U demodulator and FC0012 tuner.

Signed-off-by: Jan Vcelak j...@fcelda.cz
---

The patch adds support for the Genius TVGo DVB-T03 USB dongle.

  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index fda5c64..bb051c9 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1432,6 +1432,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {

{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
rtl2832u_props, Astrometa DVB-T2, NULL) },
+   { DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
+   rtl2832u_props, Genius TVGo DVB-T03, NULL) },
{ }
  };
  MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);




--
http://palosaari.fi/
--
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 v2 1/2] [media] rtl28xxu: add USB ID for Genius TVGo DVB-T03

[Antti Palosaari]

Applied, thanks!
Antti

On 26.02.2014 20:33, Jan Vcelak wrote:

0458:707f KYE Systems Corp. (Mouse Systems) TVGo DVB-T03 [RTL2832]

The USB dongle uses RTL2832U demodulator and FC0012 tuner.

Signed-off-by: Jan Vcelak j...@fcelda.cz
---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index fda5c64..b9eb662 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1429,6 +1429,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, Leadtek WinFast DTV Dongle mini, NULL) },
{ DVB_USB_DEVICE(USB_VID_GTEK, USB_PID_CPYTO_REDI_PC50A,
rtl2832u_props, Crypto ReDi PC 50 A, NULL) },
+   { DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
+   rtl2832u_props, Genius TVGo DVB-T03, NULL) },

{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
rtl2832u_props, Astrometa DVB-T2, NULL) },




--
http://palosaari.fi/
--
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 v2 2/2] [media] rtl28xxu: add chipset version comments into device list

[Antti Palosaari]

Applied, thanks!
Antti

On 26.02.2014 20:33, Jan Vcelak wrote:

Signed-off-by: Jan Vcelak j...@fcelda.cz
---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 3 +++
  1 file changed, 3 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index b9eb662..ab1deac 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1382,6 +1382,7 @@ static const struct dvb_usb_device_properties 
rtl2832u_props = {
  };

  static const struct usb_device_id rtl28xxu_id_table[] = {
+   /* RTL2831U devices: */
{ DVB_USB_DEVICE(USB_VID_REALTEK, USB_PID_REALTEK_RTL2831U,
rtl2831u_props, Realtek RTL2831U reference design, NULL) },
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT,
@@ -1389,6 +1390,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_WIDEVIEW, USB_PID_FREECOM_DVBT_2,
rtl2831u_props, Freecom USB2.0 DVB-T, NULL) },

+   /* RTL2832U devices: */
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2832,
rtl2832u_props, Realtek RTL2832U reference design, NULL) },
{ DVB_USB_DEVICE(USB_VID_REALTEK, 0x2838,
@@ -1432,6 +1434,7 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
{ DVB_USB_DEVICE(USB_VID_KYE, 0x707f,
rtl2832u_props, Genius TVGo DVB-T03, NULL) },

+   /* RTL2832P devices: */
{ DVB_USB_DEVICE(USB_VID_HANFTEK, 0x0131,
rtl2832u_props, Astrometa DVB-T2, NULL) },
{ }




--
http://palosaari.fi/
--
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: video4linux device name request for Software Defined Radio

[Antti Palosaari]

Hi device manager,

On 16.12.2013 20:11, Antti Palosaari wrote:

Hello,

We need new video4linux device name for Software Defined Radio devices.
Device numbers are allocated dynamically. Desired device name was
/dev/sdr, but as it seems to be already reserved, it was made decision
to apply /dev/swradio instead.


81 charvideo4linux
/dev/swradio0Software Defined Radio device


 81 charvideo4linux
  0 = /dev/swradio0 Software Defined Radio device
  1 = /dev/swradio1 Software Defined Radio device
...


Resending device name request. Should I expect it is OK to add that 
device name even without a ack from manager?



regards
Antti

--
http://palosaari.fi/
--
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: video4linux device name request for Software Defined Radio

[Antti Palosaari]

Hi device manager,

On 16.12.2013 20:11, Antti Palosaari wrote:

Hello,

We need new video4linux device name for Software Defined Radio devices.
Device numbers are allocated dynamically. Desired device name was
/dev/sdr, but as it seems to be already reserved, it was made decision
to apply /dev/swradio instead.


81 charvideo4linux
/dev/swradio0Software Defined Radio device


 81 charvideo4linux
  0 = /dev/swradio0 Software Defined Radio device
  1 = /dev/swradio1 Software Defined Radio device
...


Resending device name request. Should I expect it is OK to add that 
device name even without a ack from manager?



regards
Antti

--
http://palosaari.fi/
--
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: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

[Antti Palosaari]

Off-topic, Cc:s dropped, related to DVB / V4L2 tuner communication problems.

On 17.12.2013 07:39, Devin Heitmueller wrote:

Hi Connor,

On Tue, Dec 17, 2013 at 12:28 AM, Connor Behan  wrote:

Thanks for the detailed answer. I have tried your patch and updated the
wiki page. Would a 950 or 950Q be safer to buy next time?


The 950 has long since been obsoleted.  You cannot buy them anymore.
The 950q though is well supported and doesn't have this issue as it
uses a different chip.


On 14/12/13 05:17 PM, Devin Heitmueller wrote:

I had a patch kicking around which fixed part of the issue, but it
didn't completely work because of the lgdt3305 having AGC enabled at
chip powerup (which interferes with analog tuning on the shared
tuner), and the internal v4l-dvb APIs don't provide any easy way to
reset the AGC from the analog side of the device.


By this do you mean that the functions exist but they aren't part of the
public API? Maybe this problem can be addressed if there is ever "v4l3"
or some other reason to break compatibility.


No, these are internal APIs that dictate how the various driver
components talk to each other.  Because the V4L and DVB subsystems
were developed independently of each other, they do a really crappy
job of communicating between them (a problem which manifests itself in
particular when sharing hardware resources such as tuners).

The problem *can* be fixed, but it would likely require
extensions/changes to the basic frameworks used to communicate between
the different drivers.


That shared DVB / V4L2 tuner is one problem that I have also currently 
(SDR is on V4L2 API and DTV is provided via DVB API). I have decided to 
try model where I separate RF tuner totally independent used DVB / V4L2 
APIs, just to plain I2C driver model. Idea is here to provide needed set 
of general callbacks and communication and device binding is done via 
I2C driver model.

I am not sure though if there is any big caveats I haven't realized yet...

regards
Antti

--
http://palosaari.fi/
--
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: stable regression: tda18271_read_regs: [1-0060|M] ERROR: i2c_transfer returned: -19

[Antti Palosaari]

Off-topic, Cc:s dropped, related to DVB / V4L2 tuner communication problems.

On 17.12.2013 07:39, Devin Heitmueller wrote:

Hi Connor,

On Tue, Dec 17, 2013 at 12:28 AM, Connor Behan connor.be...@gmail.com wrote:

Thanks for the detailed answer. I have tried your patch and updated the
wiki page. Would a 950 or 950Q be safer to buy next time?


The 950 has long since been obsoleted.  You cannot buy them anymore.
The 950q though is well supported and doesn't have this issue as it
uses a different chip.


On 14/12/13 05:17 PM, Devin Heitmueller wrote:

I had a patch kicking around which fixed part of the issue, but it
didn't completely work because of the lgdt3305 having AGC enabled at
chip powerup (which interferes with analog tuning on the shared
tuner), and the internal v4l-dvb APIs don't provide any easy way to
reset the AGC from the analog side of the device.


By this do you mean that the functions exist but they aren't part of the
public API? Maybe this problem can be addressed if there is ever v4l3
or some other reason to break compatibility.


No, these are internal APIs that dictate how the various driver
components talk to each other.  Because the V4L and DVB subsystems
were developed independently of each other, they do a really crappy
job of communicating between them (a problem which manifests itself in
particular when sharing hardware resources such as tuners).

The problem *can* be fixed, but it would likely require
extensions/changes to the basic frameworks used to communicate between
the different drivers.


That shared DVB / V4L2 tuner is one problem that I have also currently 
(SDR is on V4L2 API and DTV is provided via DVB API). I have decided to 
try model where I separate RF tuner totally independent used DVB / V4L2 
APIs, just to plain I2C driver model. Idea is here to provide needed set 
of general callbacks and communication and device binding is done via 
I2C driver model.

I am not sure though if there is any big caveats I haven't realized yet...

regards
Antti

--
http://palosaari.fi/
--
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: randconfig build error with next-20130917, in drivers/staging/media/msi3101

[Antti Palosaari]

Hello Jim,

That is maybe 5th times I got that same bug report :-] It is already 
fixed. Mauro tends to handle pending patches once per release candidate, 
so I think fix will be in next very soon (during this week).


https://patchwork.kernel.org/patch/2856771/
https://lkml.org/lkml/2013/9/12/824

regards
Antti


On 09/17/2013 08:05 PM, Jim Davis wrote:

Building with the attached random configuration file,

   LD  init/built-in.o
drivers/built-in.o: In function `msi3101_probe':
/home/jim/linux-randbuild/2/drivers/staging/media/msi3101/sdr-msi3101.c:1847:
undefined reference to `vb2_vmalloc_memops'
make: *** [vmlinux] Error 1




--
http://palosaari.fi/
--
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: randconfig build error with next-20130917, in drivers/staging/media/msi3101

[Antti Palosaari]

Hello Jim,

That is maybe 5th times I got that same bug report :-] It is already 
fixed. Mauro tends to handle pending patches once per release candidate, 
so I think fix will be in next very soon (during this week).


https://patchwork.kernel.org/patch/2856771/
https://lkml.org/lkml/2013/9/12/824

regards
Antti


On 09/17/2013 08:05 PM, Jim Davis wrote:

Building with the attached random configuration file,

   LD  init/built-in.o
drivers/built-in.o: In function `msi3101_probe':
/home/jim/linux-randbuild/2/drivers/staging/media/msi3101/sdr-msi3101.c:1847:
undefined reference to `vb2_vmalloc_memops'
make: *** [vmlinux] Error 1




--
http://palosaari.fi/
--
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 -next] staging/media: fix msi3101 build errors

[Antti Palosaari]

Hello Randy,
It is already fixed, waiting for Mauro's processing.
https://patchwork.kernel.org/patch/2856771/

regards
Antti

On 09/12/2013 08:42 PM, Randy Dunlap wrote:

From: Randy Dunlap 

Fix build error when VIDEOBUF2_CORE=m and USB_MSI3101=y.

drivers/built-in.o: In function `msi3101_buf_queue':
sdr-msi3101.c:(.text+0x1298d6): undefined reference to `vb2_buffer_done'
drivers/built-in.o: In function `msi3101_cleanup_queued_bufs':
sdr-msi3101.c:(.text+0x1299c7): undefined reference to `vb2_buffer_done'
drivers/built-in.o: In function `msi3101_isoc_handler':
sdr-msi3101.c:(.text+0x12a08d): undefined reference to `vb2_plane_vaddr'
sdr-msi3101.c:(.text+0x12a0b9): undefined reference to `vb2_buffer_done'
drivers/built-in.o: In function `msi3101_probe':
sdr-msi3101.c:(.text+0x12a1c5): undefined reference to `vb2_vmalloc_memops'
sdr-msi3101.c:(.text+0x12a1d7): undefined reference to `vb2_queue_init'
drivers/built-in.o:(.rodata+0x34cf0): undefined reference to `vb2_ioctl_reqbufs'
drivers/built-in.o:(.rodata+0x34cf4): undefined reference to 
`vb2_ioctl_querybuf'
drivers/built-in.o:(.rodata+0x34cf8): undefined reference to `vb2_ioctl_qbuf'
drivers/built-in.o:(.rodata+0x34d00): undefined reference to `vb2_ioctl_dqbuf'
drivers/built-in.o:(.rodata+0x34d04): undefined reference to 
`vb2_ioctl_create_bufs'
drivers/built-in.o:(.rodata+0x34d08): undefined reference to 
`vb2_ioctl_prepare_buf'
drivers/built-in.o:(.rodata+0x34d18): undefined reference to 
`vb2_ioctl_streamon'
drivers/built-in.o:(.rodata+0x34d1c): undefined reference to 
`vb2_ioctl_streamoff'
drivers/built-in.o:(.rodata+0x35580): undefined reference to `vb2_fop_read'
drivers/built-in.o:(.rodata+0x35588): undefined reference to `vb2_fop_poll'
drivers/built-in.o:(.rodata+0x35598): undefined reference to `vb2_fop_mmap'
drivers/built-in.o:(.rodata+0x355a0): undefined reference to `vb2_fop_release'
drivers/built-in.o:(.data+0x23b40): undefined reference to 
`vb2_ops_wait_prepare'
drivers/built-in.o:(.data+0x23b44): undefined reference to `vb2_ops_wait_finish'

Signed-off-by: Randy Dunlap 
Cc: Antti Palosaari 
---
  drivers/staging/media/msi3101/Kconfig |2 ++
  1 file changed, 2 insertions(+)

--- linux-next-20130912.orig/drivers/staging/media/msi3101/Kconfig
+++ linux-next-20130912/drivers/staging/media/msi3101/Kconfig
@@ -1,3 +1,5 @@
  config USB_MSI3101
tristate "Mirics MSi3101 SDR Dongle"
depends on USB && VIDEO_DEV && VIDEO_V4L2
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_VMALLOC




--
http://palosaari.fi/
--
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 -next] staging/media: fix msi3101 build errors

[Antti Palosaari]

Hello Randy,
It is already fixed, waiting for Mauro's processing.
https://patchwork.kernel.org/patch/2856771/

regards
Antti

On 09/12/2013 08:42 PM, Randy Dunlap wrote:

From: Randy Dunlap rdun...@infradead.org

Fix build error when VIDEOBUF2_CORE=m and USB_MSI3101=y.

drivers/built-in.o: In function `msi3101_buf_queue':
sdr-msi3101.c:(.text+0x1298d6): undefined reference to `vb2_buffer_done'
drivers/built-in.o: In function `msi3101_cleanup_queued_bufs':
sdr-msi3101.c:(.text+0x1299c7): undefined reference to `vb2_buffer_done'
drivers/built-in.o: In function `msi3101_isoc_handler':
sdr-msi3101.c:(.text+0x12a08d): undefined reference to `vb2_plane_vaddr'
sdr-msi3101.c:(.text+0x12a0b9): undefined reference to `vb2_buffer_done'
drivers/built-in.o: In function `msi3101_probe':
sdr-msi3101.c:(.text+0x12a1c5): undefined reference to `vb2_vmalloc_memops'
sdr-msi3101.c:(.text+0x12a1d7): undefined reference to `vb2_queue_init'
drivers/built-in.o:(.rodata+0x34cf0): undefined reference to `vb2_ioctl_reqbufs'
drivers/built-in.o:(.rodata+0x34cf4): undefined reference to 
`vb2_ioctl_querybuf'
drivers/built-in.o:(.rodata+0x34cf8): undefined reference to `vb2_ioctl_qbuf'
drivers/built-in.o:(.rodata+0x34d00): undefined reference to `vb2_ioctl_dqbuf'
drivers/built-in.o:(.rodata+0x34d04): undefined reference to 
`vb2_ioctl_create_bufs'
drivers/built-in.o:(.rodata+0x34d08): undefined reference to 
`vb2_ioctl_prepare_buf'
drivers/built-in.o:(.rodata+0x34d18): undefined reference to 
`vb2_ioctl_streamon'
drivers/built-in.o:(.rodata+0x34d1c): undefined reference to 
`vb2_ioctl_streamoff'
drivers/built-in.o:(.rodata+0x35580): undefined reference to `vb2_fop_read'
drivers/built-in.o:(.rodata+0x35588): undefined reference to `vb2_fop_poll'
drivers/built-in.o:(.rodata+0x35598): undefined reference to `vb2_fop_mmap'
drivers/built-in.o:(.rodata+0x355a0): undefined reference to `vb2_fop_release'
drivers/built-in.o:(.data+0x23b40): undefined reference to 
`vb2_ops_wait_prepare'
drivers/built-in.o:(.data+0x23b44): undefined reference to `vb2_ops_wait_finish'

Signed-off-by: Randy Dunlap rdun...@infradead.org
Cc: Antti Palosaari cr...@iki.fi
---
  drivers/staging/media/msi3101/Kconfig |2 ++
  1 file changed, 2 insertions(+)

--- linux-next-20130912.orig/drivers/staging/media/msi3101/Kconfig
+++ linux-next-20130912/drivers/staging/media/msi3101/Kconfig
@@ -1,3 +1,5 @@
  config USB_MSI3101
tristate Mirics MSi3101 SDR Dongle
depends on USB  VIDEO_DEV  VIDEO_V4L2
+   select VIDEOBUF2_CORE
+   select VIDEOBUF2_VMALLOC




--
http://palosaari.fi/
--
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 12/18] MAINTAINERS: Update it913x patterns

[Antti Palosaari]

On 07/22/2013 03:15 AM, Joe Perches wrote:

commit d7104bffcfb ("[media] MAINTAINERS: add drivers/media/tuners/it913x*")
used the incorrect file patterns.  Fix it.

Signed-off-by: Joe Perches 
cc: Antti Palosaari 
cc: Mauro Carvalho Chehab 


Acked-by: Antti Palosaari 

PS. It wasn't that commit, but some later where driver was renamed, as 
it caused filename collision on media out-tree build.



---
  MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index aa5ccd0..7622b04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4566,7 +4566,7 @@ W:http://palosaari.fi/linux/
  Q:http://patchwork.linuxtv.org/project/linux-media/list/
  T:git git://linuxtv.org/anttip/media_tree.git
  S:Maintained
-F: drivers/media/tuners/it913x*
+F: drivers/media/tuners/tuner_it913x*

  IVTV VIDEO4LINUX DRIVER
  M:Andy Walls 




--
http://palosaari.fi/
--
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 12/18] MAINTAINERS: Update it913x patterns

[Antti Palosaari]

On 07/22/2013 03:15 AM, Joe Perches wrote:

commit d7104bffcfb ([media] MAINTAINERS: add drivers/media/tuners/it913x*)
used the incorrect file patterns.  Fix it.

Signed-off-by: Joe Perches j...@perches.com
cc: Antti Palosaari cr...@iki.fi
cc: Mauro Carvalho Chehab mche...@redhat.com


Acked-by: Antti Palosaari cr...@iki.fi

PS. It wasn't that commit, but some later where driver was renamed, as 
it caused filename collision on media out-tree build.



---
  MAINTAINERS | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/MAINTAINERS b/MAINTAINERS
index aa5ccd0..7622b04 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -4566,7 +4566,7 @@ W:http://palosaari.fi/linux/
  Q:http://patchwork.linuxtv.org/project/linux-media/list/
  T:git git://linuxtv.org/anttip/media_tree.git
  S:Maintained
-F: drivers/media/tuners/it913x*
+F: drivers/media/tuners/tuner_it913x*

  IVTV VIDEO4LINUX DRIVER
  M:Andy Walls awa...@md.metrocast.net




--
http://palosaari.fi/
--
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] [media] rtl28xxu: Add USB ID for Leadtek WinFast DTV Dongle mini

[Antti Palosaari]

On 05/15/2013 02:42 AM, Miroslav Šustek wrote:

USB ID 0413:6a03 is Leadtek WinFast DTV Dongle mini.
Decoder Realtek RTL2832U and tuner Infineon TUA9001.

Signed-off-by: Miroslav Šustek 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 


---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..d220ccc 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1408,6 +1408,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
_props, "Compro VideoMate U620F", NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
_props, "MaxMedia HU394-T", NULL) },
+   { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a03,
+   _props, "WinFast DTV Dongle mini", NULL) },
{ }
  };
  MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);




--
http://palosaari.fi/
--
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] [media] rtl28xxu: Add USB ID for Leadtek WinFast DTV Dongle mini

[Antti Palosaari]

On 05/15/2013 02:42 AM, Miroslav Šustek wrote:

USB ID 0413:6a03 is Leadtek WinFast DTV Dongle mini.
Decoder Realtek RTL2832U and tuner Infineon TUA9001.

Signed-off-by: Miroslav Šustek sustmid...@centrum.cz


Acked-by: Antti Palosaari cr...@iki.fi
Reviewed-by: Antti Palosaari cr...@iki.fi


---
  drivers/media/usb/dvb-usb-v2/rtl28xxu.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c 
b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
index 22015fe..d220ccc 100644
--- a/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
+++ b/drivers/media/usb/dvb-usb-v2/rtl28xxu.c
@@ -1408,6 +1408,8 @@ static const struct usb_device_id rtl28xxu_id_table[] = {
rtl2832u_props, Compro VideoMate U620F, NULL) },
{ DVB_USB_DEVICE(USB_VID_KWORLD_2, 0xd394,
rtl2832u_props, MaxMedia HU394-T, NULL) },
+   { DVB_USB_DEVICE(USB_VID_LEADTEK, 0x6a03,
+   rtl2832u_props, WinFast DTV Dongle mini, NULL) },
{ }
  };
  MODULE_DEVICE_TABLE(usb, rtl28xxu_id_table);




--
http://palosaari.fi/
--
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 2/2] [media] anysee: Grammar s/report the/report to/

[Antti Palosaari]

On 04/24/2013 02:36 PM, Geert Uytterhoeven wrote:

Signed-off-by: Geert Uytterhoeven 



Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 


---
  drivers/media/usb/dvb-usb-v2/anysee.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c 
b/drivers/media/usb/dvb-usb-v2/anysee.c
index 3a1f976..1760fee 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -885,7 +885,7 @@ static int anysee_frontend_attach(struct dvb_usb_adapter 
*adap)
/* we have no frontend :-( */
ret = -ENODEV;
dev_err(>udev->dev, "%s: Unsupported Anysee version. " \
-   "Please report the " \
+   "Please report to " \
".\n",
KBUILD_MODNAME);
}




--
http://palosaari.fi/
--
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 1/2] [media] anysee: Initialize ret = 0 in anysee_frontend_attach()

[Antti Palosaari]

On 04/24/2013 02:36 PM, Geert Uytterhoeven wrote:

drivers/media/usb/dvb-usb-v2/anysee.c: In function ‘anysee_frontend_attach’:
drivers/media/usb/dvb-usb-v2/anysee.c:641: warning: ‘ret’ may be used 
uninitialized in this function

And gcc is right (see the ANYSEE_HW_507T case), so initialize ret to zero
to fix this.

Signed-off-by: Geert Uytterhoeven 


Acked-by: Antti Palosaari 
Reviewed-by: Antti Palosaari 



---
  drivers/media/usb/dvb-usb-v2/anysee.c |2 +-
  1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/media/usb/dvb-usb-v2/anysee.c 
b/drivers/media/usb/dvb-usb-v2/anysee.c
index a20d691..3a1f976 100644
--- a/drivers/media/usb/dvb-usb-v2/anysee.c
+++ b/drivers/media/usb/dvb-usb-v2/anysee.c
@@ -638,7 +638,7 @@ static int anysee_frontend_attach(struct dvb_usb_adapter 
*adap)
  {
struct anysee_state *state = adap_to_priv(adap);
struct dvb_usb_device *d = adap_to_d(adap);
-   int ret;
+   int ret = 0;
u8 tmp;
struct i2c_msg msg[2] = {
{




--
http://palosaari.fi/
--
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/