[Qemu-devel] [PATCH 1/7] backends: Fix warning from Sparse

[Qemu-devel] [PATCH 1/7] backends: Fix warning from Sparse

[Stefan Weil]

Sparse report:

backends/tpm.c:39:5: warning: returning void-valued expression

Signed-off-by: Stefan Weil <sw@weilnetz.de>
---
 backends/tpm.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/backends/tpm.c b/backends/tpm.c
index 01860c4..4efe367 100644
--- a/backends/tpm.c
+++ b/backends/tpm.c
@@ -36,7 +36,7 @@ void tpm_backend_destroy(TPMBackend *s)
 {
     TPMBackendClass *k = TPM_BACKEND_GET_CLASS(s);
 
-    return k->ops->destroy(s);
+    k->ops->destroy(s);
 }
 
 int tpm_backend_init(TPMBackend *s, TPMState *state,
-- 
2.1.4

Re: [Qemu-devel] [PATCH 1/7] backends: Fix warning from Sparse

[Michael Tokarev]

Applied all 7 to -trivial.

Is it intentional that there's no cover letter for the series?

Thanks,

/mjt

Re: [Qemu-devel] [PATCH 1/7] backends: Fix warning from Sparse

[Stefan Weil]

Am 10.03.2015 um 07:04 schrieb Michael Tokarev:
> Applied all 7 to -trivial.
>
> Is it intentional that there's no cover letter for the series?
>
> Thanks,
>
> /mjt

No, that was my mistake. Please excuse also the cris patch which I sent 
twice.
I did not notice that it already had caused trouble, nor did I notice 
that I had already sent it.
In my local patch queue (~ 50 patches) there was even a 2nd cris patch
which removed the unused variables...

Regards
Stefan

Re: [Qemu-devel] [PATCH 1/7] backends: Fix warning from Sparse

[Michael Tokarev]

10.03.2015 09:22, Stefan Weil wrote:

> No, that was my mistake. Please excuse also the cris patch which I sent twice.
> I did not notice that it already had caused trouble, nor did I notice that I had already sent it.
> In my local patch queue (~ 50 patches) there was even a 2nd cris patch
> which removed the unused variables...

No problems with that (except that we bothered Peter twice
with this cris thing already, and I really mean "we", since
it escaped my testing and accurate review too, and it was
twice too, so I'm as guilty if not more).

And this situation suggests that I should process and submit
patches a) more carefully and b) faster.  So it is, again,
good portion of my fault.  Not doing trivial-patches merging
for 3 weeks and rushing a whole lot in one go without that
good review isn't going to work well.

Thank you for the good work!  And it really is good, while
boring...

/mjt