Re: modprobing 'vidtv' doesn't really do anything

Re: modprobing 'vidtv' doesn't really do anything

[Daniel W. S. Almeida]

With your current patch the probing code is actually called now, Mauro. Thanks!

As for the sparse errors you've pointed out earlier, I'm at a loss. Yes,
I have noticed them, but let's look at an example (they're all mostly
the same)

>SPARSE:drivers/media/test-drivers/vidtv/vidtv_psi.c
>drivers/media/test-drivers/vidtv/vidtv_psi.c:174:43: warning: Using plain
>integer as NULL pointer

This actually refers to this line:

>struct psi_write_args psi_args = {0}

Which seems to me like a valid way to zero-initialize a struct in C? 

Next up is...

>SPARSE:drivers/media/test-drivers/vidtv/vidtv_pes.c
>drivers/media/test-drivers/vidtv/vidtv_pes.c:80:54: warning: missing
>braces around initializer

I assume this refers to the following line, which is the same deal as above.

>struct vidtv_pes_optional_pts pts         = {0};


And then there's this, which is an actual mistake. I have mostly
eliminated these, but this guy has slipped by.

>SPARSE:drivers/media/test-drivers/vidtv/vidtv_s302m.c
>drivers/media/test-drivers/vidtv/vidtv_s302m.c:430:36: warning:
>incorrect type in assignment (different base types)


Just one more thing. This change on vidtv_bridge.c:

>vidtv_bridge_check_demod_lock(struct vidtv_dvb *dvb, u32 n)
>
>dvb->fe[n]->ops.read_status(dvb->fe[n], &status);
>
>-	return status == (FE_HAS_SIGNAL |
>-	FE_HAS_CARRIER |
>-	FE_HAS_VITERBI |
>-	FE_HAS_SYNC |
>-	FE_HAS_LOCK);
>+	status = FE_HAS_SIGNAL |
>+	FE_HAS_CARRIER |
>+	FE_HAS_VITERBI |
>+	FE_HAS_SYNC |
>+	FE_HAS_LOCK;
>+
>+	return status;
>}

I did not understand that. Why was the boolean expression replaced by an
assignment? This was so eventually we could drop packets or simulate
some sort of noise in the event that one of these flags was not set, as
we've discussed at some point.

Thanks,

- Daniel

Re: [Linux-kernel-mentees] modprobing 'vidtv' doesn't really do anything

[Daniel W. S. Almeida]

With your current patch the probing code is actually called now, Mauro. Thanks!

As for the sparse errors you've pointed out earlier, I'm at a loss. Yes,
I have noticed them, but let's look at an example (they're all mostly
the same)

>SPARSE:drivers/media/test-drivers/vidtv/vidtv_psi.c
>drivers/media/test-drivers/vidtv/vidtv_psi.c:174:43: warning: Using plain
>integer as NULL pointer

This actually refers to this line:

>struct psi_write_args psi_args = {0}

Which seems to me like a valid way to zero-initialize a struct in C? 

Next up is...

>SPARSE:drivers/media/test-drivers/vidtv/vidtv_pes.c
>drivers/media/test-drivers/vidtv/vidtv_pes.c:80:54: warning: missing
>braces around initializer

I assume this refers to the following line, which is the same deal as above.

>struct vidtv_pes_optional_pts pts         = {0};


And then there's this, which is an actual mistake. I have mostly
eliminated these, but this guy has slipped by.

>SPARSE:drivers/media/test-drivers/vidtv/vidtv_s302m.c
>drivers/media/test-drivers/vidtv/vidtv_s302m.c:430:36: warning:
>incorrect type in assignment (different base types)


Just one more thing. This change on vidtv_bridge.c:

>vidtv_bridge_check_demod_lock(struct vidtv_dvb *dvb, u32 n)
>
>dvb->fe[n]->ops.read_status(dvb->fe[n], &status);
>
>-	return status == (FE_HAS_SIGNAL |
>-	FE_HAS_CARRIER |
>-	FE_HAS_VITERBI |
>-	FE_HAS_SYNC |
>-	FE_HAS_LOCK);
>+	status = FE_HAS_SIGNAL |
>+	FE_HAS_CARRIER |
>+	FE_HAS_VITERBI |
>+	FE_HAS_SYNC |
>+	FE_HAS_LOCK;
>+
>+	return status;
>}

I did not understand that. Why was the boolean expression replaced by an
assignment? This was so eventually we could drop packets or simulate
some sort of noise in the event that one of these flags was not set, as
we've discussed at some point.

Thanks,

- Daniel
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

Re: [Linux-kernel-mentees] modprobing 'vidtv' doesn't really do anything

[Mauro Carvalho Chehab]

Em Tue, 19 May 2020 04:13:07 -0300
"Daniel W. S. Almeida" <dwlsalmeida@gmail.com> escreveu:

> With your current patch the probing code is actually called now, Mauro. Thanks!
> 
> As for the sparse errors you've pointed out earlier, I'm at a loss. Yes,
> I have noticed them, but let's look at an example (they're all mostly
> the same)
> 
> >SPARSE:drivers/media/test-drivers/vidtv/vidtv_psi.c
> >drivers/media/test-drivers/vidtv/vidtv_psi.c:174:43: warning: Using plain
> >integer as NULL pointer  
> 
> This actually refers to this line:
> 
> >struct psi_write_args psi_args = {0}  
> 
> Which seems to me like a valid way to zero-initialize a struct in C? 

Actually, passing 0 is not the right thing there. The init code
should either be using gcc style:

	struct psi_write_args psi_args = {}  

or something where the first argument matches the first argument
of the struct, as, according with the C99 specs, doing something
like:

	struct foo {
		void *bar;
		...
	};

	struct psi_write_args psi_args = {NULL};

Would do is to use NULL to initialize "bar" variable. 

See comments about that at https://stackoverflow.com/questions/11152160/initializing-a-struct-to-0:

	"Reference C99 Standard 6.7.8.21:

	If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration."

The other values would be initialized with the "same as objects that
have static storage", e. g. with zero.

In other words, you need to check what's the first element of the
struct, when using C99 initialization. E. g, if the first element
is a pointer, the init should be:

	struct some_struct_that_starts_with_a_pointer = {NULL};

Tricky.

> 
> Next up is...
> 
> >SPARSE:drivers/media/test-drivers/vidtv/vidtv_pes.c
> >drivers/media/test-drivers/vidtv/vidtv_pes.c:80:54: warning: missing
> >braces around initializer  
> 
> I assume this refers to the following line, which is the same deal as above.
> 
> >struct vidtv_pes_optional_pts pts         = {0};  
> 
> 
> And then there's this, which is an actual mistake. I have mostly
> eliminated these, but this guy has slipped by.
> 
> >SPARSE:drivers/media/test-drivers/vidtv/vidtv_s302m.c
> >drivers/media/test-drivers/vidtv/vidtv_s302m.c:430:36: warning:
> >incorrect type in assignment (different base types)  
> 
> 
> Just one more thing. This change on vidtv_bridge.c:
> 
> >vidtv_bridge_check_demod_lock(struct vidtv_dvb *dvb, u32 n)
> >
> >dvb->fe[n]->ops.read_status(dvb->fe[n], &status);
> >
> >-	return status == (FE_HAS_SIGNAL |
> >-	FE_HAS_CARRIER |
> >-	FE_HAS_VITERBI |
> >-	FE_HAS_SYNC |
> >-	FE_HAS_LOCK);
> >+	status = FE_HAS_SIGNAL |
> >+	FE_HAS_CARRIER |
> >+	FE_HAS_VITERBI |
> >+	FE_HAS_SYNC |
> >+	FE_HAS_LOCK;
> >+
> >+	return status;
> >}  
> 
> I did not understand that. Why was the boolean expression replaced by an
> assignment? This was so eventually we could drop packets or simulate
> some sort of noise in the event that one of these flags was not set, as
> we've discussed at some point.

Ah, sorry, I remember gcc complained about that (can't remember why).

On a very quick look (it was 2am here when I looked at the code), it
sounded to me  that you wanted to assign status to some value and return
it.

Thanks,
Mauro
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

Re: modprobing 'vidtv' doesn't really do anything

[Daniel W. S. Almeida]

Hi Mauro,

> Actually, passing 0 is not the right thing there. The init code
> should either be using gcc style:
> 
> 	struct psi_write_args psi_args = {}  
> 

I did not know that! Now fixed by replacing " = {0}" with " = {}"

As I said, the probing functions are actually called, but now I am
running into other issues..

I have sent a new revision (v6), in which I have squashed your patch
plus a few changes to the bridge driver.

In vidtv_bridge.c:266, dvb_module_probe always returns NULL. That is
because i2c_client_has_driver(client) fails, because client->dev.driver
is NULL.

I suspect this line is to blame, but I am not sure..
>	i2c_adapter->dev.parent = &dvb->pdev->dev;


Also, when this happens, some error handling code will run starting at
vidtv_bridge.c:383, but that will not remove the modules (i.e. lsmod
will still list the bridge and the demod). Is this expected? Should I
call vidtv_bridge_exit manually?

Also, should I worry about this?

>BUG: KASAN: user-memory-access in >do_init_module+0x1d/0x330
>Read of size 8 at addr 000000008322fe90 by task >modprobe/1290

I did not call this directly and I don't see a way to trace it back to
my code just by looking at "do_init_module+0x1d/0x330"

Thanks

- Daniel

Re: [Linux-kernel-mentees] modprobing 'vidtv' doesn't really do anything

[Daniel W. S. Almeida]

Hi Mauro,

> Actually, passing 0 is not the right thing there. The init code
> should either be using gcc style:
> 
> 	struct psi_write_args psi_args = {}  
> 

I did not know that! Now fixed by replacing " = {0}" with " = {}"

As I said, the probing functions are actually called, but now I am
running into other issues..

I have sent a new revision (v6), in which I have squashed your patch
plus a few changes to the bridge driver.

In vidtv_bridge.c:266, dvb_module_probe always returns NULL. That is
because i2c_client_has_driver(client) fails, because client->dev.driver
is NULL.

I suspect this line is to blame, but I am not sure..
>	i2c_adapter->dev.parent = &dvb->pdev->dev;


Also, when this happens, some error handling code will run starting at
vidtv_bridge.c:383, but that will not remove the modules (i.e. lsmod
will still list the bridge and the demod). Is this expected? Should I
call vidtv_bridge_exit manually?

Also, should I worry about this?

>BUG: KASAN: user-memory-access in >do_init_module+0x1d/0x330
>Read of size 8 at addr 000000008322fe90 by task >modprobe/1290

I did not call this directly and I don't see a way to trace it back to
my code just by looking at "do_init_module+0x1d/0x330"

Thanks

- Daniel
_______________________________________________
Linux-kernel-mentees mailing list
Linux-kernel-mentees@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/linux-kernel-mentees

Re: modprobing 'vidtv' doesn't really do anything

[Daniel W. S. Almeida]

Yeah the Makefile was broken, although I corrected it in the last
revision, so this warning should be gone already?

I guess you're looking at v4, in which case I have sent in new code that
hopefully addresses the things you pointed out in the last code review :)

I will try what you said regarding the platform bus and report back.

- Daniel.

modprobing 'vidtv' doesn't really do anything

[Daniel W. S. Almeida]

Hi Mauro!

I am trying to iron out the bugs in the virtual DVB driver I have been
working on for the past few months.

modprobing vidtv_bridge apparently works, i.e. 'vidtv_bridge' gets
listed in the output of 'lsmod' and there's a message on dmesg warning
against loading out of tree modules.

It does not seem like the probe function actually runs, though. I have
added a printk call in vidtv_bridge_i2c_probe() but it does not output
anything to dmesg.

Also, I am using QEMU + KGDB and the debugger does not break into this
function (or into any other function in vidtv_bridg.c) at all, although
it can actually get the addresses for them, i.e.

4       breakpoint     keep y   0xffffffffc0000025 in
vidtv_bridge_i2c_probe at drivers/media/test-drivers/vidtv/vidtv_bridg.c:373
5       breakpoint     keep y   0xffffffffc0000523 in
vidtv_bridge_i2c_remove at drivers/media/test-drivers/vidtv/vidtv_bridg.c:416

It can't find these, though:
2       breakpoint     keep y   <PENDING>          drivers/media/test-drivers/vidtv/vidtv_bridg.c:vidtv_bridge_driver_exit
3       breakpoint     keep y   <PENDING>          drivers/media/test-drivers/vidtv/vidtv_bridg.c:vidtv_bridge_driver_init


>The best is to start using dvbv5 tools inside v4l-utils.
>The first step to check if the demod code was properly loaded is to run:
>$ dvb-fe-tool 

I tried this, but to no avail.
>WARNING device dvb0.frontend0 not found

I am stuck, can I get some help with this issue?

Thanks!

-Daniel