From: Mauro Carvalho Chehab <mchehab@kernel.org>
To: "Daniel W. S. Almeida" <dwlsalmeida@gmail.com>
Cc: Linux Media Mailing List <linux-media@vger.kernel.org>,
"linux-kernel-mentees@lists.linuxfoundation.org\"\"\"
<linux-kernel-mentees@lists.linuxfoundation.org>"@osuosl.org
Subject: Re: [Linux-kernel-mentees] modprobing 'vidtv' doesn't really do anything
Date: Tue, 19 May 2020 10:48:34 +0200 [thread overview]
Message-ID: <20200519104834.3c4bf5d7@coco.lan> (raw)
In-Reply-To: <C564849C-4E08-4994-A694-A736626548E2@getmailspring.com>
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
next prev parent reply other threads:[~2020-05-20 12:44 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200517022115.5ce8136c@coco.lan>
2020-05-19 7:13 ` [Linux-kernel-mentees] modprobing 'vidtv' doesn't really do anything Daniel W. S. Almeida
2020-05-19 7:13 ` Daniel W. S. Almeida
2020-05-19 8:48 ` Mauro Carvalho Chehab [this message]
2020-05-20 7:22 ` [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-20 7:22 ` Daniel W. S. Almeida
2020-05-16 22:09 [Linux-kernel-mentees] " Daniel W. S. Almeida
2020-05-16 23:29 ` Mauro Carvalho Chehab
2020-05-16 23:42 ` Mauro Carvalho Chehab
2020-05-17 0:04 ` Daniel W. S. Almeida
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20200519104834.3c4bf5d7@coco.lan \
--to=mchehab@kernel.org \
--cc="linux-kernel-mentees@lists.linuxfoundation.org\"\"\" <linux-kernel-mentees@lists.linuxfoundation.org>"@osuosl.org \
--cc=dwlsalmeida@gmail.com \
--cc=linux-media@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.