Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

The patch was wrong. Actyally the message says the opposite!

This reverts commit 101891a7.

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

keep the typo as define to avoid compatibility issues.
Remove it later when we are sure
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@gmail.com>

this will fix g++ warnings and will not affect the gcc and C logic even
if `(void *)` is perfectly legal in C
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

This is a C library that it can be used by C++ programs as well.
So the library header will be included in some C++ program and g++
will rise warnings like this:

------
fmcadc-lib.h: In function 'int fmcadc_mshot_buf_max_size_get(fmcadc_dev*, int*)':
fmcadc-lib.h:202:74: warning: deprecated conversion from string constant to 'char*'
[-Wwrite-strings]
         return fmcadc_get_param(dev, "cset0/max-sample-mshot", NULL, value);
------

This patch will suppress all these warning because what we are doing is
correct. The message says that it's deprecated; probably at some point
in time it will not be supported at all and we will see errors instead
of warnings. This patch is suppressing only the warnings.

For the time being we prefer this solution instead of casting strings
to `(char *)` because it's ugly and unclear from C point of view.
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Signed-off-by: Juan David Gonzalez Cobas <dcobas@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

It should make the code clear since the +1 and -1 (for the trigger sample)
is done only when accessing the hardware. Otherwise, we cansider the
trigger sample as part of the post samples
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>
Signed-off-by: Dimitris Lampridis <Dimitris.Lampridis@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

In bitstream 4.1 there is a register that tells me what is the maximum
number of samples for each shot in multi-shot mode.

So with this patch I removed the hardcoded value and I retrieve at load time
the value from the hardware
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Now the hardware does not make any distinction between single-shot and
multi-shot. The "remaining shot" register work transparently for both
Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>

Signed-off-by: Federico Vaga <federico.vaga@cern.ch>