| ed375186 | 25-Feb-2025 |
Rodrigo Gobbi <[email protected]> |
staging: gpib: change return type of t1_delay function to report errors
The current code returns "unsigned int" and it doesn't handle errors
correctly if it happens during ioctl call for t1 delay co
staging: gpib: change return type of t1_delay function to report errors
The current code returns "unsigned int" and it doesn't handle errors
correctly if it happens during ioctl call for t1 delay configuration.
The ni_usb_t1_delay(), from NI, is the only function returning -1
at this point. The caller, t1_delay_ioctl(), doesn't check for errors
and sets board->t1_nano_sec to -1 and returns success.
The board->t1_nano_sec value is also used in ni_usb_setup_t1_delay()
besides the ioctl call and a value of -1 is treated as being above 1100ns.
It may or may not have a noticeable effect, but it's obviously not right
considering the content of ni_usb_setup_t1_delay().
Typical delays are in the 200-2000 range, but definitely not more
than INT_MAX so we can fix this code by changing the return type to int
and adding a check for errors. While we're at it, lets change the error
code in ni_usb_t1_delay() from -1 and instead propagate the error from
ni_usb_write_registers().
Fixes: 4e127de14fa7 ("staging: gpib: Add National Instruments USB GPIB driver")
Signed-off-by: Rodrigo Gobbi <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| 840459da | 19-Mar-2025 |
Michael Rubin <[email protected]> |
staging: gpib: common: struct gpib_board
Using Linux code style for struct gpib_board.
Adhering to Linux code style.
In general, a pointer, or a struct that has elements that can reasonably be
dir
staging: gpib: common: struct gpib_board
Using Linux code style for struct gpib_board.
Adhering to Linux code style.
In general, a pointer, or a struct that has elements that can reasonably be
directly accessed should never be a typedef.
Signed-off-by: Michael Rubin <[email protected]>
Acked-By: Dave Penkler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| 3e2bcc16 | 14-Jan-2025 |
Dave Penkler <[email protected]> |
staging: gpib: Use C99 syntax and make static
Some drivers were still using the old syntax for initializing
structs:
field : value;
This caused sparse to emit the following warning, for example:
co
staging: gpib: Use C99 syntax and make static
Some drivers were still using the old syntax for initializing
structs:
field : value;
This caused sparse to emit the following warning, for example:
common/gpib_os.c:2026:1: warning: obsolete struct initializer, use C99 syntax
Use C99 syntax:
.field = value;
Some local structs and arrays were not declared static causing
sparse to emit the following warning, for example:
warning: symbol 'ib_fops' was not declared. Should it be static?
Declare the local structs and arrays as static.
Signed-off-by: Dave Penkler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| b3beeeee | 14-Jan-2025 |
Dave Penkler <[email protected]> |
staging: gpib: Avoid plain integers as NULL pointers
A number of drivers were comparing request_region() with 0,
others were passing 0 instead of NULL as a pointer argument.
This led to the followi
staging: gpib: Avoid plain integers as NULL pointers
A number of drivers were comparing request_region() with 0,
others were passing 0 instead of NULL as a pointer argument.
This led to the following sparse warning, for example:
cb7210/cb7210.c:1043:72: warning: Using plain integer as NULL pointer
Use !request_region() to test for NULL return and use NULL instead
of 0 as pointer parameter.
Signed-off-by: Dave Penkler <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| fec866a0 | 13-Dec-2024 |
Arnd Bergmann <[email protected]> |
staging: gpib: use ioport_map
The tnt4882 backend has a rather elabolate way of abstracting the
PIO and MMIO based hardware variants, duplicating the functionality
of ioport_map() in a less portable
staging: gpib: use ioport_map
The tnt4882 backend has a rather elabolate way of abstracting the
PIO and MMIO based hardware variants, duplicating the functionality
of ioport_map() in a less portable way.
Change it to use ioport_map() with ioread8()/iowrite8() to do
this more easily.
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| d76e1402 | 16-Oct-2024 |
Arnd Bergmann <[email protected]> |
staging: gpib: use proper format string in request_module
Using a string variable as a format causes a -Wformat-security
warning. Since the only use of the temporary module_string[] is to hold
the s
staging: gpib: use proper format string in request_module
Using a string variable as a format causes a -Wformat-security
warning. Since the only use of the temporary module_string[] is to hold
the sprintf() output, just pass the format string and argument directly
to request_module().
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| 78ecb037 | 16-Oct-2024 |
Arnd Bergmann <[email protected]> |
staging: gpib: make port I/O code conditional
A few of the helper modules contain functions for both IORESOURCE_MEM
and IORESOURCE_IO type access, with the latter not being supported
on all architec
staging: gpib: make port I/O code conditional
A few of the helper modules contain functions for both IORESOURCE_MEM
and IORESOURCE_IO type access, with the latter not being supported
on all architectures but also not used by all the drivers.
Add #ifdef checks around these to allow building the library code
and use it on MMIO-only configurations.
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|
| b8989f45 | 16-Oct-2024 |
Arnd Bergmann <[email protected]> |
staging: gpib: avoid unused const variables
Variables that are 'static const' but not used anywhere cause a warning
with "gcc -Wunused-const-variable", which we may want to enable by default
in the
staging: gpib: avoid unused const variables
Variables that are 'static const' but not used anywhere cause a warning
with "gcc -Wunused-const-variable", which we may want to enable by default
in the future.
The gpib code already has a mix of 'enum' and 'static const' variables
for named constants, so convert the ones that are causing problems to
enums as well, or move them closer to the only users where possible.
Signed-off-by: Arnd Bergmann <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
show more ...
|