A bulk callback transfer can be initiated from two places -
inside kernel interface or from user interface. However,
the callback data pointer 'cb_data' is used for tracking both
sets of data pointer. This commit tracks the callback
data pointer from user interface (named as 'cb_userdata') separately,
in the bulk transfer service callback.
This is esentially done by adding a 'void __user *cb_userdata' for
tracking __user pointers in vchiq_bulk and vchiq_completion_data
structs. Furthermore, the 'cb_userdata' data pointer is appended to
the vchiq_service's callback signature.
Separating the two callback data pointers ('cb_data' and 'cb_userdata')
fixes the sparse warnings around mixing userspace and kernel space
pointers.
As there are no additional sparse warnings left for vc04_services,
drop the relevant entry from the TODO.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20241023110406.885199-7-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
In a previous commit, struct vchiq_bulk 'userdata' got renamed to
'cb_data' since it is the data pointer passed in
VCHIQ_BULK_CALLBACK_MODE's callback. Since struct vchiq_completion_data*
structs also has 'bulk_userdata' for completion records, rename
'bulk_userdata' member to 'cb_data' for these structs as well.
This brings consistency and clarity for the struct members. No
functional change in this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20241023110406.885199-5-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Currently, struct bulk_waiter is allocated for VCHIQ_BULK_MODE_BLOCKING
bulk transfer and its pointer is assigned to vchiq_bulk->userdata. Avoid
this kind of piggybacking and introduce a dedicate 'waiter' member in
struct vchiq_bulk.
The 'userdata' is meant for VCHIQ_BULK_MODE_CALLBACK mode, to pass user
specified parameter to the actual callback function.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20241023110406.885199-3-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Sven Van Asbroeck contributed this driver in 2019.
The following reasons lead to the removal:
- This driver generates maintenance workload
- only 11 patches during the last 3 years. Part of the patches seem to be
motivated because of maintenance (for example - remove deprecated
function)
- Maintainer lost interest, last "Reviewed-by:" is May 2021
- no blog about usage of this driver
The staging subsystem is the way for drivers into the kernel - at current
speed and interest this is never going to happen. I think that fieldbus
is an interesting topic. But when almost nobody cares about this driver,
it does not make sense to keep it. Please consider that support will
remain for years in the longterm kernels.
Link: https://lore.kernel.org/linux-staging/96ae2b42-c0ce-4d9a-8933-eb874dc5589b@gmail.com/T/#u
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/20241102191436.23177-1-philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
rtw_ndev_notifier_call() does not do anything other then
a netdev_dbg() + always returning NOTIFY_DONE.
Remove the no-op notifier.
This also fixes a WARN() when unbinding + rebinding the driver
which was caused by the remove() method not unregistering
the notifier.
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Link: https://lore.kernel.org/r/20241024181052.67031-1-hdegoede@redhat.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
vchiq_bulk_xfer_queue_msg_killable() is a common function between
various bulk transfer code paths (blocking, callback and no-callback).
These code paths were simplified earlier by passing a populated
struct vchiq_bulk pointer in order to avoid open-coding the parameters
required to initiate a bulk transfer.
Now simplify the vchiq_bulk_xfer_queue_msg_killable() in a similar way
i.e. avoid open-coding the function parameters and pass the struct
vchiq_bulk pointer directly, coming from the various bulk transfer code
paths.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20241017133629.216672-6-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Two functions create_pagelist() and vchiq_prepare_bulk_data()
open code bulk data arguments ('size' and 'dir') in their function
signatures which can easily be obtained by struct vchiq_bulk pointer.
Retrieve the arguments from vchiq_bulk pointer instead and reduce
the number of arguments passed in create_pagelist() and
vchiq_bulk_prepare_data().
No functional changes intended in this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Link: https://lore.kernel.org/r/20241017133629.216672-3-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
A number of GPIB drivers fail to build when CONFIG_HAS_IOPORT is disabled,
which can be avoided with a CONFIG_ISA_BUS or CONFIG_PCMCIA dependency.
For completeness, mark all of the new device drivers with a dependency
on whichever bus they use, and hide the symbols for chip drivers that
are already selected by teh device drivers using them.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241016111521.1143191-6-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241016111521.1143191-5-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
On architectures that don't support the ISA DMA API, this causes a build
failure. The corresponding dma_alloc() call is already in an #ifdef,
so use the same one for dma_free().
Note that nothing seems to set PC2_DMA, so parts of this driver
are likely unused. ISA DMA usually does not work on PCI or PCMCIA
devices, only on physical ISA slots.
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241016111521.1143191-4-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
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 <arnd@arndb.de>
Link: https://lore.kernel.org/r/20241016111521.1143191-3-arnd@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The variable `complement_count` is assigned a value which is again
overwritten in the next statement.
Fix this by removing the first value assigning statement
This issue was reported by Coverity Scan.
Report:
CID 1600790: (#1 of 1): Unused value (UNUSED_VALUE)
assigned_value: Assigning value from length to complement_count here,
but that stored value is overwritten before it can be used.
Signed-off-by: Everest K.C. <everestkc@everestkc.com.np>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20241016075544.4125-1-everestkc@everestkc.com.np
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clang warns (or errors with CONFIG_WERROR=y):
drivers/staging/gpib/fmh_gpib/fmh_gpib.c:970:43: error: variable 'residue' is uninitialized when used here [-Werror,-Wuninitialized]
970 | (int)(*bytes_read), (int)length, (int)residue);
| ^~~~~~~
residue is never initialized in this function and it is not used outside
of an error print. Just remove it altogether, as it is likely not
necessary in this function, as this same exact statement in present in
fmh_gpib_dma_read().
Fixes: 8e4841a088 ("staging: gpib: Add Frank Mori Hess FPGA PCI GPIB driver")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Link: https://lore.kernel.org/r/20241015-staging-gpib-fmh-fix-residue-used-uninitialized-v1-1-23ef05b099da@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Clang warns (or errors with CONFIG_WERROR=y):
In file included from drivers/staging/gpib/ines/ines_gpib.c:19:
drivers/staging/gpib/include/gpib_pci_ids.h:3:9: error: '__GPIB_PCI_IDS_H' is used as a header guard here, followed by #define of a different macro [-Werror,-Wheader-guard]
3 | #ifndef __GPIB_PCI_IDS_H
| ^~~~~~~~~~~~~~~~
drivers/staging/gpib/include/gpib_pci_ids.h:4:9: note: '__GPIB_LINUX_PCI_IDS_H' is defined here; did you mean '__GPIB_PCI_IDS_H'?
4 | #define __GPIB_LINUX_PCI_IDS_H
| ^~~~~~~~~~~~~~~~~~~~~~
| __GPIB_PCI_IDS_H
Fix the define to match the guard like the note suggests, as that is
clearly what was intended here.
Fixes: 6c52d5e3cd ("staging: gpib: Add common include files for GPIB drivers")
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Tested-by: Javier Carrasco <javier.carrasco.cruz@gmail.com>
Link: https://lore.kernel.org/r/20241015-staging-gpib-fix-pci-header-guard-v1-1-dfa45fe8d63f@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
The variable `in_data` is freed, but used later in the code.
Fix it by moving the freeing the memory after it use has been
completed.
This issue was reported by Coverity Scan.
Report:
CID 1600783: (#1 of 1): Use after free (USE_AFTER_FREE)
19. pass_freed_arg: Passing freed pointer in_data as an argument to
ni_usb_dump_raw_block.
Fixes: 4e127de14f ("staging: gpib: Add National Instruments USB GPIB driver")
Signed-off-by: Everest K.C. <everestkc@everestkc.com.np>
Reviewed-by: Shuah Khan <skhan@linuxfoundation.org>
Link: https://lore.kernel.org/r/20241015215157.18571-1-everestkc@everestkc.com.np
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
