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>
If the service is not in VCHIQ_SRVSTATE_LISTENING state, it is
implied that the message is dealt with and parse_open() should return.
If this is the case, simply jump the code flow to return site using
'goto done;' statement.
This helps to lower the indentation of
if (service->srvstate == VCHIQ_SRVSTATE_LISTENING)
conditional branch.
No functional changes intended in this patch.
Signed-off-by: Umang Jain <umang.jain@ideasonboard.com>
Reviewed-by: Stefan Wahren <wahrenst@gmx.net>
Reviewed-by: Dan Carpenter <dan.carpenter@linaro.org>
Link: https://lore.kernel.org/r/20241013112128.397249-6-umang.jain@ideasonboard.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Forest Bond contributed this driver in 2009.
The following reasons lead to the removal:
- This driver generates maintenance workload
- This driver has a maximum 54MBit/s as it supports only 802.11 b/g.
Peak throughput is 3MBytes/s but this lasts only for a second.
Typically throughput is 1.7MBytes/s.
- Depending on the number of devices on the channel the device looses
connection and cannot reconnect for 5-60 seconds. Watching a youtube
video is OK because of the buffer. But surfing can then be really a
pain.
- Its form factor is mini PCI (not miniPCIe) that is old and large.
- Hardly not to buy.
Link: https://lore.kernel.org/linux-staging/2024100923-player-directive-ffa8@gregkh/T/#t
Signed-off-by: Philipp Hortmann <philipp.g.hortmann@gmail.com>
Link: https://lore.kernel.org/r/20241010164221.13392-1-philipp.g.hortmann@gmail.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
It breaks the build so disable that option for now.
It shouldn't be needed anyway, the normal in-kernel debugging facilities
should be used instead.
Cc: Dave Penkler <dpenkler@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
