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
