Commit Graph

8762 Commits

Author SHA1 Message Date
Ian Abbott
7379e6baed staging: comedi: amplc_pci230: fix null pointer deref on interrupt
The interrupt handler `pci230_interrupt()` causes a null pointer
dereference for a PCI260 card.  There is no analog output subdevice for
a PCI260.  The `dev->write_subdev` subdevice pointer and therefore the
`s_ao` subdevice pointer variable will be `NULL` for a PCI260.  The
following call near the end of the interrupt handler results in the null
pointer dereference for a PCI260:

	comedi_handle_events(dev, s_ao);

Fix it by only calling the above function if `s_ao` is valid.

Note that the other uses of `s_ao` in the calls
`pci230_handle_ao_nofifo(dev, s_ao);` and `pci230_handle_ao_fifo(dev,
s_ao);` will never be reached for a PCI260, so they are safe.

Fixes: 39064f2328 ("staging: comedi: amplc_pci230: use comedi_handle_events()")
Cc: <stable@vger.kernel.org> # v3.19+
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-07-01 08:50:15 +02:00
Ian Abbott
e36472145a staging: comedi: use dma_mmap_coherent for DMA-able buffer mmap
Comedi's acquisition buffer allocation code can allocate the buffer from
normal kernel memory or from DMA coherent memory depending on the
`dma_async_dir` value in the comedi subdevice.  (A value of `DMA_NONE`
causes the buffer to be allocated from normal kernel memory.  Other
values cause the buffer to be allocated from DMA coherent memory.)   The
buffer currently consists of a bunch of page-sized blocks that are
vmap'ed into a contiguous range of virtual addresses. The pages are also
mmap'able into user address space.  For DMA'able buffers, these
page-sized blocks are allocated by `dma_alloc_coherent()`.

For DMA-able buffers, the DMA API is currently abused in various ways,
the most serious abuse being the calling of `virt_to_page()` on the
blocks allocated by `dma_alloc_coherent()` and passing those pages to
`vmap()` (for mapping to the kernels vmalloc address space) and via
`page_to_pfn()` to `remap_pfn_range()` (for mmap'ing to user space).  it
also uses the `__GFP_COMP` flag when allocating the blocks, and marks
the allocated pages as reserved (which is unnecessary for DMA coherent
allocations).

The code can be changed to get rid of the vmap'ed address altogether if
necessary, since there are only a few places in the comedi code that use
the vmap'ed address directly and we also keep a list of the kernel
addresses for the individual pages prior to the vmap operation. This
would add some run-time overhead to buffer accesses.  The real killer is
the mmap operation.

For mmap, the address range specified in the VMA needs to be mmap'ed to
the individually allocated page-sized blocks.  That is not a problem
when the pages are allocated from normal kernel memory as the individual
pages can be remapped by `remap_pfn_range()`, but it is a problem when
the page-sized blocks are allocated by `dma_alloc_coherent()` because
the DMA API currently has no support for splitting a VMA across multiple
blocks of DMA coherent memory (or rather, no support for mapping part of
a VMA range to a single block of DMA coherent memory).

In order to comply with the DMA API and allow the buffer to be mmap'ed,
the buffer needs to be allocated as a single block by a single call to
`dma_alloc_coherent()`, freed by a single call to `dma_free_coherent()`,
and mmap'ed to user space by a single call to `dma_mmap_coherent()`.
This patch changes the buffer allocation, freeing, and mmap'ing code to
do that, with the unfortunate consequence that buffer allocation is more
likely to fail.  It also no longer uses the `__GFP_COMP` flag when
allocating DMA coherent memory, no longer marks the
allocated pages of DMA coherent memory as reserved, and no longer vmap's
the DMA coherent memory pages (since they are contiguous anyway).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: Christoph Hellwig <hch@lst.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-26 09:32:13 +08:00
Colin Ian King
7c23143199 staging: comedi: usbdux: remove redundant initialization of fx2delay
Variable fx2delay is being initialized to a value that is never read
and is being re-assigned a few statements later. The initialization
is redundant and can be removed.

Addresses-Coverity: ("Unused value")
Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-06-18 08:59:40 +02:00
Linus Torvalds
e0dccbdf5a Staging / IIO driver patches for 5.2-rc1
Here is the big staging and iio driver update for 5.2-rc1.
 
 Lots of tiny fixes all over the staging and IIO driver trees here, along
 with some new IIO drivers.
 
 Also we ended up deleting two drivers, making this pull request remove a
 few hundred thousand lines of code, always a nice thing to see.  Both of
 the drivers removed have been replaced with "real" drivers in their
 various subsystem directories, and they will be coming to you from those
 locations during this merge window.
 
 There are some core vt/selection changes in here, that was due to some
 cleanups needed for the speakup fixes.  Those have all been acked by the
 various subsystem maintainers (i.e. me), so those are ok.
 
 We also added a few new drivers, for some odd hardware, giving new
 developers plenty to work on with basic coding style cleanups to come in
 the near future.
 
 Other than that, nothing unusual here.
 
 All of these have been in linux-next for a while with no reported
 issues, other than an odd gcc warning for one of the new drivers that
 should be fixed up soon.
 
 Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
 -----BEGIN PGP SIGNATURE-----
 
 iG0EABECAC0WIQT0tgzFv3jCIUoxPcsxR9QN2y37KQUCXNHGMQ8cZ3JlZ0Brcm9h
 aC5jb20ACgkQMUfUDdst+ynQRACgwtlC6DFsEFwCplYxQXP5uzuIVTMAoJ61xzC0
 Qim7K31f5ulaa3GJuhzo
 =zEY5
 -----END PGP SIGNATURE-----

Merge tag 'staging-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging

Pull staging / IIO driver updates from Greg KH:
 "Here is the big staging and iio driver update for 5.2-rc1.

  Lots of tiny fixes all over the staging and IIO driver trees here,
  along with some new IIO drivers.

  The "counter" subsystem was added in here as well, as it is needed by
  the IIO drivers and subsystem.

  Also we ended up deleting two drivers, making this pull request remove
  a few hundred thousand lines of code, always a nice thing to see. Both
  of the drivers removed have been replaced with "real" drivers in their
  various subsystem directories, and they will be coming to you from
  those locations during this merge window.

  There are some core vt/selection changes in here, that was due to some
  cleanups needed for the speakup fixes. Those have all been acked by
  the various subsystem maintainers (i.e. me), so those are ok.

  We also added a few new drivers, for some odd hardware, giving new
  developers plenty to work on with basic coding style cleanups to come
  in the near future.

  Other than that, nothing unusual here.

  All of these have been in linux-next for a while with no reported
  issues, other than an odd gcc warning for one of the new drivers that
  should be fixed up soon"

[ I fixed up the warning myself  - Linus ]

* tag 'staging-5.2-rc1' of git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/staging: (663 commits)
  staging: kpc2000: kpc_spi: Fix build error for {read,write}q
  Staging: rtl8192e: Remove extra space before break statement
  Staging: rtl8192u: ieee80211: Fix if-else indentation warning
  Staging: rtl8192u: ieee80211: Fix indentation errors by removing extra spaces
  staging: most: cdev: fix chrdev_region leak in mod_exit
  staging: wlan-ng: Fix improper SPDX comment style
  staging: rtl8192u: ieee80211: Resolve ERROR reported by checkpatch
  staging: vc04_services: bcm2835-camera: Compress two lines into one line
  staging: rtl8723bs: core: Use !x in place of NULL comparison.
  staging: rtl8723bs: core: Prefer using the BIT Macro.
  staging: fieldbus: anybus-s: fix wait_for_completion_timeout return handling
  staging: kpc2000: fix up build problems with readq()
  staging: rtlwifi: move remaining phydm .h files
  staging: rtlwifi: strip down phydm .h files
  staging: rtlwifi: delete the staging driver
  staging: fieldbus: anybus-s: rename bus id field to avoid confusion
  staging: fieldbus: anybus-s: keep device bus id in bus endianness
  Staging: sm750fb: Change *array into *const array
  staging: rtl8192u: ieee80211: Fix spelling mistake
  staging: rtl8192u: ieee80211: Replace bit shifting with BIT macro
  ...
2019-05-07 13:31:29 -07:00
Linus Torvalds
dd4e5d6106 Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb())
Remove mmiowb() from the kernel memory barrier API and instead, for
 architectures that need it, hide the barrier inside spin_unlock() when
 MMIO has been performed inside the critical section.
 -----BEGIN PGP SIGNATURE-----
 
 iQEzBAABCgAdFiEEPxTL6PPUbjXGY88ct6xw3ITBYzQFAlzMFaUACgkQt6xw3ITB
 YzRICQgAiv7wF/yIbBhDOmCNCAKDO59chvFQWxXWdGk/aAB56kwKAMXJgLOvlMG/
 VRuuLyParTFQETC3jaxKgnO/1hb+PZLDt2Q2KqixtjIzBypKUPWvK2sf6THhSRF1
 GK0DBVUd1rCrWrR815+SPb8el4xXtdBzvAVB+Fx35PXVNpdRdqCkK+EQ6UnXGokm
 rXXHbnfsnquBDtmb4CR4r2beH+aNElXbdt0Kj8VcE5J7f7jTdW3z6Q9WFRvdKmK7
 yrsxXXB2w/EsWXOwFp0SLTV5+fgeGgTvv8uLjDw+SG6t0E0PebxjNAflT7dPrbYL
 WecjKC9WqBxrGY+4ew6YJP70ijLBCw==
 =aC8m
 -----END PGP SIGNATURE-----

Merge tag 'arm64-mmiowb' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux

Pull mmiowb removal from Will Deacon:
 "Remove Mysterious Macro Intended to Obscure Weird Behaviours (mmiowb())

  Remove mmiowb() from the kernel memory barrier API and instead, for
  architectures that need it, hide the barrier inside spin_unlock() when
  MMIO has been performed inside the critical section.

  The only relatively recent changes have been addressing review
  comments on the documentation, which is in a much better shape thanks
  to the efforts of Ben and Ingo.

  I was initially planning to split this into two pull requests so that
  you could run the coccinelle script yourself, however it's been plain
  sailing in linux-next so I've just included the whole lot here to keep
  things simple"

* tag 'arm64-mmiowb' of git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux: (23 commits)
  docs/memory-barriers.txt: Update I/O section to be clearer about CPU vs thread
  docs/memory-barriers.txt: Fix style, spacing and grammar in I/O section
  arch: Remove dummy mmiowb() definitions from arch code
  net/ethernet/silan/sc92031: Remove stale comment about mmiowb()
  i40iw: Redefine i40iw_mmiowb() to do nothing
  scsi/qla1280: Remove stale comment about mmiowb()
  drivers: Remove explicit invocations of mmiowb()
  drivers: Remove useless trailing comments from mmiowb() invocations
  Documentation: Kill all references to mmiowb()
  riscv/mmiowb: Hook up mmwiob() implementation to asm-generic code
  powerpc/mmiowb: Hook up mmwiob() implementation to asm-generic code
  ia64/mmiowb: Add unconditional mmiowb() to arch_spin_unlock()
  mips/mmiowb: Add unconditional mmiowb() to arch_spin_unlock()
  sh/mmiowb: Add unconditional mmiowb() to arch_spin_unlock()
  m68k/io: Remove useless definition of mmiowb()
  nds32/io: Remove useless definition of mmiowb()
  x86/io: Remove useless definition of mmiowb()
  arm64/io: Remove useless definition of mmiowb()
  ARM/io: Remove useless definition of mmiowb()
  mmiowb: Hook up mmiowb helpers to spinlocks and generic I/O accessors
  ...
2019-05-06 16:57:52 -07:00
Ian Abbott
a4965d98b4 staging: comedi: comedi_isadma: Use a non-NULL device for DMA API
The "comedi_isadma" module calls `dma_alloc_coherent()` and
`dma_free_coherent()` with a NULL device pointer which is no longer
allowed.  If the `hw_dev` member of the `struct comedi_device` has been
set to a valid device, that can be used instead.  Unfortunately, all the
current users of the "comedi_isadma" module leave the `hw_dev` member
set to NULL.  In that case, fall back to using the comedi "class" device
pointed to by the `class_dev` member if that is non-NULL.  In that case,
make it "DMA-capable" with a coherent DMA mask set to the ISA bus limit
of 16MB (24 bits).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-27 15:00:35 +02:00
Greg Kroah-Hartman
817de6b859 Merge 5.1-rc6 into staging-next
We want the fixes in here as well as this resolves an iio driver merge
issue.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-21 23:18:44 +02:00
Moses Christopher
24c9f9b66a staging: comedi: use help instead of ---help--- in Kconfig
- Resolve the following warning from the Kconfig,
    "WARNING: prefer 'help' over '---help---' for new help texts"

Signed-off-by: Moses Christopher <moseschristopherb@gmail.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 15:01:50 +02:00
Ian Abbott
7c2c18202c staging: comedi: dt9812: Call mutex_destroy() on private mutex
`dt9812_detach()` is the Comedi "detach" handler for the dt9812 driver.
When it is called, the private data for the device is about to be freed.
The private data contains a mutex `devpriv->mut` that was initialized
when the private data was allocated.  Call `mutex_destroy()` to mark it
as invalid.

Also remove the calls to `mutex_lock()` and `mutex_unlock()` from
`dt9812_detach()` as the mutex is only being used around a call to
`usb_set_intfdata()` to clear the USB interface's driver data pointer.
The mutex lock seems redundant here, especially as it is about to be
destroyed.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:59:37 +02:00
Ian Abbott
6e1167444c staging: comedi: ni_usb6501: Call mutex_destroy() on private mutex
`ni6501_detach()` is the Comedi "detach" handler for the ni_usb6501
driver.  It is called when the private data for the device is about to
be freed.  The private data contains a mutex `devpriv->mut` that was
initialized when the private data was allocated.  Call `mutex_destroy()`
to mark it as invalid.

Also remove the calls to `mutex_lock()` and `mutex_unlock()` from
`ni6501_detach()`.  The only other locks of the mutex are by some of the
Comedi instruction handlers that cannot contend with the "detach"
handler for this mutex.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:59:37 +02:00
Ian Abbott
3c03c470f4 staging: comedi: usbdux: Call mutex_destroy() on private mutex
`usbdux_detach()` is the Comedi "detach" handler for the usbdux driver.
When it is called, the private data for the device is about to be freed.
The private date contains a mutex `devpriv->mut` that was initialized
when the private data was allocated.  Call `mutex_destroy()` to mark it
as invalid.

The calls to `mutex_lock()` and `mutex_unlock()` are probably not
required, especially as the mutex is about to be destroyed, but leave
them alone for now.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:59:37 +02:00
Ian Abbott
35756f3dbf staging: comedi: usbduxfast: Call mutex_destroy() on private mutex
`usbduxfast_detach()` is the Comedi "detach" handler for the usbduxfast
driver.  When it is called, the private data for the device is about to
be freed.  The private date contains a mutex `devpriv->mut` that was
initialized when the private data was allocated.  Call `mutex_destroy()`
to mark it as invalid.

The calls to `mutex_lock()` and `mutex_unlock()` in
`usbduxfast_detach()` are probably not required, especially as the mutex
is about to be destroyed, but leave them alone for now.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:59:36 +02:00
Ian Abbott
2cd0869672 staging: comedi: usbduxsigma: Call mutex_destroy() on private mutex
`usbduxsigma_detach()` is the Comedi "detach" handler for the
usbduxsigma driver.  When it is called, the private data for the device
is about to be freed.  The private date contains a mutex `devpriv->mut`
that was initialized when the private data was allocated.  Call
`mutex_destroy()` to mark it as invalid.

The calls to `mutex_lock()` and `mutex_unlock()` in
`usbduxsigma_detach()` are probably not required, especially as the
mutex is about to be destroyed, but leave them alone for now.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:59:36 +02:00
Ian Abbott
f44303e852 staging: comedi: Add lockdep_assert_held() calls for dev->attach_lock
There are not a lot of functions in the core comedi module that require
the R/W semaphore `attach_lock` in `struct comedi_device` to be locked
(although there are a few functions that require at least one of
`attach_lock` and `mutex` to be locked).  One function that requires the
caller to lock `attach_lock` is `comedi_device_detach_cleanup()` so add
a call to `lockdep_assert_held()` to check and document that.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:33:41 +02:00
Ian Abbott
77c21b626b staging: comedi: Add lockdep_assert_held() calls for dev->mutex
Lots of functions in the core comedi module expect the mutex in `struct
comedi_device` to be held, so add calls to `lockdep_assert_held()` to
check and document that.  An unusual case is the calls to
`lockdep_assert_held()` after successful return from
`comedi_alloc_board_minor()` which allocates a `struct comedi_device`
and returns with its mutex locked.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:33:41 +02:00
Ian Abbott
f439696c81 staging: comedi: don't release mutex too early in comedi_auto_config()
`comedi_auto_config()` uses `dev->class_dev` for logging a kernel
message after releasing `dev->mutex`.  There is an unlikely possibility
that the Comedi device `dev` will have been removed by the
`COMEDI_DEVCONFIG` ioctl() command.  Keep hold of the mutex until the
kernel message has been sent to prevent that.  The function can call
`comedi_release_hardware_device()` on error.  In that case, the mutex
must be unlocked before that.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-19 14:33:33 +02:00
Ian Abbott
6229fed9ee staging: comedi: dyna_pci10xx: Set number of AO channels to 1
The "dyna_pci10xx" driver supports the Dynalog India PCI-1050.  There
seems to be very little online information available about this card,
but as far as I can tell[*], it only has 1 AO (analog output) channel,
not 16 AO channels as reported in the Comedi subdevice information.
Besides, the Comedi "insn_write" handler for the AO subdevice takes no
account of channel numbers.  Change the `n_chans` member of the AO
subdevice structure to 1 to reflect this.

[*] The card is no longer mentioned on the manufacturer's web-site and I
couldn't find any archived page for the site on archive.org.  I found
part of a scientific paper which describes the card as having a single
channel D/A converter:
<http://shodhganga.inflibnet.ac.in/bitstream/10603/150646/15/15_chapter%205.pdf>.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17 12:40:51 +02:00
Ian Abbott
4138b1d44f staging: comedi: dyna_pci10xx: Don't bother configuring len_chanlist
In the Comedi "attach" and "auto_attach" handlers that set up the Comedi
subdevices, there is no need to initialize the `len_chanlist` member of
Comedi subdevices that do not support Comedi asynchronous streaming
commands.  They can be left set to the initial zeroed out value and
the Comedi core will change the `len_chanlist` member to 1 afterwards in
that case.  The "dyna_pci10xx" driver currently sets the `len_chanlist`
members to the same value as the `n_chan` ("number of channels") member,
but this is unnecessary as none of them support asynchronous streaming.
Remove the initialization of `len_chanlist` from all the subdevices.
This will affect the information reported by the COMEDI_SUBDINFO ioctl
slightly.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17 12:40:51 +02:00
Ian Abbott
af4b54a2e5 staging: comedi: ni_usb6501: Fix possible double-free of ->usb_rx_buf
`ni6501_alloc_usb_buffers()` is called from `ni6501_auto_attach()` to
allocate RX and TX buffers for USB transfers.  It allocates
`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`.  If the
allocation of `devpriv->usb_tx_buf` fails, it frees
`devpriv->usb_rx_buf`, leaving the pointer set dangling, and returns an
error.  Later, `ni6501_detach()` will be called from the core comedi
module code to clean up.  `ni6501_detach()` also frees both
`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
`devpriv->usb_rx_buf` may have already beed freed, leading to a
double-free error.  Fix it bu removing the call to
`kfree(devpriv->usb_rx_buf)` from `ni6501_alloc_usb_buffers()`, relying
on `ni6501_detach()` to free the memory.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17 11:59:24 +02:00
Ian Abbott
660cf4ce9d staging: comedi: ni_usb6501: Fix use of uninitialized mutex
If `ni6501_auto_attach()` returns an error, the core comedi module code
will call `ni6501_detach()` to clean up.  If `ni6501_auto_attach()`
successfully allocated the comedi device private data, `ni6501_detach()`
assumes that a `struct mutex mut` contained in the private data has been
initialized and uses it.  Unfortunately, there are a couple of places
where `ni6501_auto_attach()` can return an error after allocating the
device private data but before initializing the mutex, so this
assumption is invalid.  Fix it by initializing the mutex just after
allocating the private data in `ni6501_auto_attach()` before any other
errors can be retturned.  Also move the call to `usb_set_intfdata()`
just to keep the code a bit neater (either position for the call is
fine).

I believe this was the cause of the following syzbot crash report
<https://syzkaller.appspot.com/bug?extid=cf4f2b6c24aff0a3edf6>:

usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
usb 1-1: string descriptor 0 read error: -71
comedi comedi0: Wrong number of endpoints
ni6501 1-1:0.233: driver 'ni6501' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 585 Comm: kworker/0:3 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xe8/0x16e lib/dump_stack.c:113
 assign_lock_key kernel/locking/lockdep.c:786 [inline]
 register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
 __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
 lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
 __mutex_lock_common kernel/locking/mutex.c:925 [inline]
 __mutex_lock+0xfe/0x12b0 kernel/locking/mutex.c:1072
 ni6501_detach+0x5b/0x110 drivers/staging/comedi/drivers/ni_usb6501.c:567
 comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
 comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
 comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
 comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
 comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
 comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
 comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
 usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
 really_probe+0x2da/0xb10 drivers/base/dd.c:509
 driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
 __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
 __device_attach+0x223/0x3a0 drivers/base/dd.c:844
 bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
 device_add+0xad2/0x16e0 drivers/base/core.c:2106
 usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
 generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
 usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
 really_probe+0x2da/0xb10 drivers/base/dd.c:509
 driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
 __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
 __device_attach+0x223/0x3a0 drivers/base/dd.c:844
 bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
 device_add+0xad2/0x16e0 drivers/base/core.c:2106
 usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
 hub_port_connect drivers/usb/core/hub.c:5089 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
 port_event drivers/usb/core/hub.c:5350 [inline]
 hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
 kthread+0x313/0x420 kernel/kthread.c:253
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352

Reported-by: syzbot+cf4f2b6c24aff0a3edf6@syzkaller.appspotmail.com
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-17 11:59:24 +02:00
Ian Abbott
663d294b47 staging: comedi: vmk80xx: Fix possible double-free of ->usb_rx_buf
`vmk80xx_alloc_usb_buffers()` is called from `vmk80xx_auto_attach()` to
allocate RX and TX buffers for USB transfers.  It allocates
`devpriv->usb_rx_buf` followed by `devpriv->usb_tx_buf`.  If the
allocation of `devpriv->usb_tx_buf` fails, it frees
`devpriv->usb_rx_buf`,  leaving the pointer set dangling, and returns an
error.  Later, `vmk80xx_detach()` will be called from the core comedi
module code to clean up.  `vmk80xx_detach()` also frees both
`devpriv->usb_rx_buf` and `devpriv->usb_tx_buf`, but
`devpriv->usb_rx_buf` may have already been freed, leading to a
double-free error.  Fix it by removing the call to
`kfree(devpriv->usb_rx_buf)` from `vmk80xx_alloc_usb_buffers()`, relying
on `vmk80xx_detach()` to free the memory.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 13:05:33 +02:00
Ian Abbott
08b7c2f920 staging: comedi: vmk80xx: Fix use of uninitialized semaphore
If `vmk80xx_auto_attach()` returns an error, the core comedi module code
will call `vmk80xx_detach()` to clean up.  If `vmk80xx_auto_attach()`
successfully allocated the comedi device private data,
`vmk80xx_detach()` assumes that a `struct semaphore limit_sem` contained
in the private data has been initialized and uses it.  Unfortunately,
there are a couple of places where `vmk80xx_auto_attach()` can return an
error after allocating the device private data but before initializing
the semaphore, so this assumption is invalid.  Fix it by initializing
the semaphore just after allocating the private data in
`vmk80xx_auto_attach()` before any other errors can be returned.

I believe this was the cause of the following syzbot crash report
<https://syzkaller.appspot.com/bug?extid=54c2f58f15fe6876b6ad>:

usb 1-1: config 0 has no interface number 0
usb 1-1: New USB device found, idVendor=10cf, idProduct=8068, bcdDevice=e6.8d
usb 1-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0
usb 1-1: config 0 descriptor??
vmk80xx 1-1:0.117: driver 'vmk80xx' failed to auto-configure device.
INFO: trying to register non-static key.
the code is fine but needs lockdep annotation.
turning off the locking correctness validator.
CPU: 0 PID: 12 Comm: kworker/0:1 Not tainted 5.1.0-rc4-319354-g9a33b36 #3
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011
Workqueue: usb_hub_wq hub_event
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0xe8/0x16e lib/dump_stack.c:113
 assign_lock_key kernel/locking/lockdep.c:786 [inline]
 register_lock_class+0x11b8/0x1250 kernel/locking/lockdep.c:1095
 __lock_acquire+0xfb/0x37c0 kernel/locking/lockdep.c:3582
 lock_acquire+0x10d/0x2f0 kernel/locking/lockdep.c:4211
 __raw_spin_lock_irqsave include/linux/spinlock_api_smp.h:110 [inline]
 _raw_spin_lock_irqsave+0x44/0x60 kernel/locking/spinlock.c:152
 down+0x12/0x80 kernel/locking/semaphore.c:58
 vmk80xx_detach+0x59/0x100 drivers/staging/comedi/drivers/vmk80xx.c:829
 comedi_device_detach+0xed/0x800 drivers/staging/comedi/drivers.c:204
 comedi_device_cleanup.part.0+0x68/0x140 drivers/staging/comedi/comedi_fops.c:156
 comedi_device_cleanup drivers/staging/comedi/comedi_fops.c:187 [inline]
 comedi_free_board_dev.part.0+0x16/0x90 drivers/staging/comedi/comedi_fops.c:190
 comedi_free_board_dev drivers/staging/comedi/comedi_fops.c:189 [inline]
 comedi_release_hardware_device+0x111/0x140 drivers/staging/comedi/comedi_fops.c:2880
 comedi_auto_config.cold+0x124/0x1b0 drivers/staging/comedi/drivers.c:1068
 usb_probe_interface+0x31d/0x820 drivers/usb/core/driver.c:361
 really_probe+0x2da/0xb10 drivers/base/dd.c:509
 driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
 __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
 __device_attach+0x223/0x3a0 drivers/base/dd.c:844
 bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
 device_add+0xad2/0x16e0 drivers/base/core.c:2106
 usb_set_configuration+0xdf7/0x1740 drivers/usb/core/message.c:2021
 generic_probe+0xa2/0xda drivers/usb/core/generic.c:210
 usb_probe_device+0xc0/0x150 drivers/usb/core/driver.c:266
 really_probe+0x2da/0xb10 drivers/base/dd.c:509
 driver_probe_device+0x21d/0x350 drivers/base/dd.c:671
 __device_attach_driver+0x1d8/0x290 drivers/base/dd.c:778
 bus_for_each_drv+0x163/0x1e0 drivers/base/bus.c:454
 __device_attach+0x223/0x3a0 drivers/base/dd.c:844
 bus_probe_device+0x1f1/0x2a0 drivers/base/bus.c:514
 device_add+0xad2/0x16e0 drivers/base/core.c:2106
 usb_new_device.cold+0x537/0xccf drivers/usb/core/hub.c:2534
 hub_port_connect drivers/usb/core/hub.c:5089 [inline]
 hub_port_connect_change drivers/usb/core/hub.c:5204 [inline]
 port_event drivers/usb/core/hub.c:5350 [inline]
 hub_event+0x138e/0x3b00 drivers/usb/core/hub.c:5432
 process_one_work+0x90f/0x1580 kernel/workqueue.c:2269
 worker_thread+0x9b/0xe20 kernel/workqueue.c:2415
 kthread+0x313/0x420 kernel/kthread.c:253
 ret_from_fork+0x3a/0x50 arch/x86/entry/entry_64.S:352

Reported-by: syzbot+54c2f58f15fe6876b6ad@syzkaller.appspotmail.com
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Cc: stable <stable@vger.kernel.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 13:05:33 +02:00
Colin Ian King
b368fa114a staging: comedi: adv_pci1710: fix spelling mistake: "droput" -> "dropout"
There is a spelling mistake in a dev_error message. Fix it.

Signed-off-by: Colin Ian King <colin.king@canonical.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 12:57:54 +02:00
Hariprasad Kelam
28f69ae49b staging: comedi: dt2811: Fix spelling mistake
changes interupts --> interrupts to fix warning reported by checkpatch
tool

Signed-off-by: Hariprasad Kelam <hariprasad.kelam@gmail.com>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 12:57:53 +02:00
YueHaibing
3935a6fb4b staging: comedi: dyna_pci10xx: remove set but not used variables 'chan' and range'
Fixes gcc '-Wunused-but-set-variable' warning:

drivers/staging/comedi/drivers/dyna_pci10xx.c: In function 'dyna_pci10xx_insn_write_ao':
drivers/staging/comedi/drivers/dyna_pci10xx.c:109:21: warning:
 variable 'range' set but not used [-Wunused-but-set-variable]
  unsigned int chan, range;

drivers/staging/comedi/drivers/dyna_pci10xx.c:109:15: warning:
 variable 'chan' set but not used [-Wunused-but-set-variable]
  unsigned int chan, range;

They are never used since introduction in commit 16a7373a8e ("Staging:
comedi: add dyna_pci10xx driver")

Signed-off-by: YueHaibing <yuehaibing@huawei.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-16 12:57:53 +02:00
Will Deacon
fb24ea52f7 drivers: Remove explicit invocations of mmiowb()
mmiowb() is now implied by spin_unlock() on architectures that require
it, so there is no reason to call it from driver code. This patch was
generated using coccinelle:

	@mmiowb@
	@@
	- mmiowb();

and invoked as:

$ for d in drivers include/linux/qed sound; do \
spatch --include-headers --sp-file mmiowb.cocci --dir $d --in-place; done

NOTE: mmiowb() has only ever guaranteed ordering in conjunction with
spin_unlock(). However, pairing each mmiowb() removal in this patch with
the corresponding call to spin_unlock() is not at all trivial, so there
is a small chance that this change may regress any drivers incorrectly
relying on mmiowb() to order MMIO writes between CPUs using lock-free
synchronisation. If you've ended up bisecting to this commit, you can
reintroduce the mmiowb() calls using wmb() instead, which should restore
the old behaviour on all architectures other than some esoteric ia64
systems.

Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Will Deacon <will.deacon@arm.com>
2019-04-08 12:01:02 +01:00
Greg Kroah-Hartman
7beaea2945 staging: comedi: quatec_daqp_cs: add proper SPDX identifier to driver
By default all files without license information are under the default
license of the kernel, which is GPL version 2.  Because of this, add the
GPL-2.0 identifier to the quatec_daqp_cs driver which did not have any license
identifiers in it at all.

Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Cc: Brent Baccala <baccala@freesoft.org>
Cc: David A. Schleef <ds@schleef.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-03 11:10:16 +02:00
Greg Kroah-Hartman
97ed8eab2a staging: add missing SPDX lines to Makefile files
There are a few remaining drivers/staging/*/Makefile files that do not
have SPDX identifiers in them.  Add the correct GPL-2.0 identifier to
them to make scanning tools happy.

Reviewed-by: Mukesh Ojha <mojha@codeaurora.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-03 11:10:15 +02:00
Greg Kroah-Hartman
99b75a4e32 staging: add missing SPDX lines to Kconfig files
There are a few remaining drivers/staging/*/Kconfig files that do not
have SPDX identifiers in them.  Add the correct GPL-2.0 identifier to
them to make scanning tools happy.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-03 11:10:15 +02:00
Sanjana Sanikommu
557e36194e staging: comedi: Prefer using BIT macro in various files.
Challenge suggested by coccinelle.

Replace bit shifting on 1 with the BIT(x) macro.
Coccinelle script:

@@
constant c;
@@

-(1 << c)
+BIT(c)

Signed-off-by: Sanjana Sanikommu <sanjana99reddy99@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-01 19:31:11 +02:00
Payal Kshirsagar
643cd0a25d staging: comedi: use !x in place of NULL comparison
Challenge suggested by coccinelle.
Avoid NULL comparison, compare using boolean operator.

Signed-off-by: Payal Kshirsagar <payal.s.kshirsagar.98@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-01 19:23:42 +02:00
Greg Kroah-Hartman
b397f82585 Merge 5.1-rc3 into staging-next
We want those fixes and this resolves an erofs merge conflict.

Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-04-01 07:49:24 +02:00
Ian Abbott
5c724e197e staging: comedi: ni_tio: Use data[insn->n-1] in ni_tio_insn_write()
The `insn_write` handler for the counter subdevices
(`ni_tio_insn_write()`) writes a single data value `data[0]` to the
channel.  Technically, `insn->n` specifies the number of successive
values from `data[]` to write to the channel, but when there is little
benefit in writing multiple data values, the usual Comedi convention is
to just write the last data value `data[insn->n - 1]`.  Change the
function to follow that convention and use `data[insn->n - 1]` instead
of `data[0]`.  (In practice, `insn->n` would normally be 1 anyway.)

Also follow the usual Comedi convention and return `insn->n` from the
handler to indicate success instead of 0 (although any non-negative
return value will do).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-29 17:10:18 +01:00
Arash Fotouhi
83cdfc17a9 Staging: comedi: ni_mio_common.c: Added blank line after declarations
Added blank line after declarations.

Signed-off-by: Arash Fotouhi <arash@arashfotouhi.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-22 15:16:27 +01:00
Ian Abbott
49634aa7d9 staging: comedi: ni_mio_common: use insn->n in ni_m_series_eeprom_insn_read()
The `insn_read` handler for the EEPROM subdevice on M-series boards
(`ni_m_series_eeprom_insn_read()`) currently ignores `insn->n` (the
number of samples to read) and assumes a single sample is to be read
into `data[0]`.  Fortunately, the Comedi core ensures that `data[]` has
a length of at least 16 so there is no problem with array bounds.

The usual Comedi convention for `insn_read` handlers is to read the same
channel `insn->n` times into successive elements of `data[]` so let's do
that.  (Each channel corresponds to a single EEPROM address.)  In this
case, the data value comes from a local copy of the EEPROM contents.

Also, follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative value will do).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-20 08:25:17 +01:00
Ian Abbott
018768ccc7 staging: comedi: ni_mio_common: use insn->n in ni_eeprom_insn_read()
The `insn_read` handler for the EEPROM subdevice on E-series boards
(`ni_eeprom_insn_read()`) currently ignores `insn->n` (the number of
samples to read) and assumes a single sample is to be read into
`data[0]`.  Fortunately, the Comedi core ensures that `data[]` has a
length of at least 16 so there is no problem with array bounds.

The usual Comedi convention for `insn_read` handlers is to read the same
channel `insn->n` times into successive elements of `data[]` so let's do
that.  (Each channel number corresponds to a single EEPROM address.)
Since we do not expect the EEPROM data at a particular address to change
between readings, let's just read it once and copy the value `insn->n`
times.

Also, follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative value will do).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-20 08:25:17 +01:00
Ian Abbott
776d25ff5b staging: comedi: ni_mio_common: use insn->n in ni_calib_insn_read()
The `insn_read` handler for the calibration subdevice
(`ni_calib_insn_read()`) currently ignores `insn->n` (the number of
samples to read) and assumes a single sample is to be read into
`data[0]`.  Fortunately, the Comedi core ensures that `data[]` has a
length of at least 16, so there is no problem with array bounds.

The usual Comedi convention for `insn_read` handlers is to read the same
channel `insn->n` times into successive elements of `data[]`, so let's
do that.

Also, follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative value will do).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-20 08:25:17 +01:00
Ian Abbott
fe57d1e113 staging: comedi: ni_mio_common: Use insn->n in ni_calib_insn_write()
The `insn_write` handler for the calibration subdevice
(`ni_calib_insn_write()`) currently ignores `insn->n` (the number of
samples to write) and assumes a single sample is to be written, but
`insn->n` could be 0, meaning no samples should be written, in which
case `data[0]` is invalid.

Change `ni_calib_insn_write()` to only write to the calibration device
if `insn->n > 0`.  There isn't much point writing all the values when
`insn->n > 1`, so just write the last one (`data[insn->n - 1]`).

Also follow the usual Comedi convention and return `insn->n` from the
handler to indicate success (although any non-negative return value will
do as far as the Comedi core is concerned).

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-20 08:25:17 +01:00
Ian Abbott
bafd9c6405 staging: comedi: ni_mio_common: Fix divide-by-zero for DIO cmdtest
`ni_cdio_cmdtest()` validates Comedi asynchronous commands for the DIO
subdevice (subdevice 2) of supported National Instruments M-series
cards.  It is called when handling the `COMEDI_CMD` and `COMEDI_CMDTEST`
ioctls for this subdevice.  There are two causes for a possible
divide-by-zero error when validating that the `stop_arg` member of the
passed-in command is not too large.

The first cause for the divide-by-zero is that calls to
`comedi_bytes_per_scan()` are only valid once the command has been
copied to `s->async->cmd`, but that copy is only done for the
`COMEDI_CMD` ioctl.  For the `COMEDI_CMDTEST` ioctl, it will use
whatever was left there by the previous `COMEDI_CMD` ioctl, if any.
(This is very likely, as it is usual for the application to use
`COMEDI_CMDTEST` before `COMEDI_CMD`.) If there has been no previous,
valid `COMEDI_CMD` for this subdevice, then `comedi_bytes_per_scan()`
will return 0, so the subsequent division in `ni_cdio_cmdtest()` of
`s->async->prealloc_bufsz / comedi_bytes_per_scan(s)` will be a
divide-by-zero error.  To fix this error, call a new function
`comedi_bytes_per_scan_cmd(s, cmd)`, based on the existing
`comedi_bytes_per_scan(s)` but using a specified `struct comedi_cmd` for
its calculations.  (Also refactor `comedi_bytes_per_scan()` to call the
new function.)

Once the first cause for the divide-by-zero has been fixed, the second
cause is that `comedi_bytes_per_scan_cmd()` can legitimately return 0 if
the `scan_end_arg` member of the `struct comedi_cmd` being tested is 0.
Fix it by only performing the division (and validating that `stop_arg`
is no more than the maximum value) if `comedi_bytes_per_scan_cmd()`
returns a non-zero value.

The problem was reported on the COMEDI mailing list here:
https://groups.google.com/forum/#!topic/comedi_list/4t9WlHzMhKM

Reported-by: Ivan Vasilyev <grabesstimme@gmail.com>
Tested-by: Ivan Vasilyev <grabesstimme@gmail.com>
Fixes: f164cbf98f ("staging: comedi: ni_mio_common: add finite regeneration to dio output")
Cc: <stable@vger.kernel.org> # 4.6+
Cc: Spencer E. Olson <olsonse@umich.edu>
Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-03-18 07:57:58 +01:00
Ian Abbott
97c64322b8 staging: comedi: ni_tio: Allocate shadow regs for each counter chip
The "ni_tio" module contains code to allocate, destroy and operate on a
`struct ni_gpct_device`, which represents a number of counters spread
over one or more blocks (or "chips").  `struct ni_gpct_device` includes
an array member `regs` holding shadow copies of register values.
Unfortunately, this is currently shared by each block of counters so
they interfere with each other.  This is a problem for the "ni_660x"
module, which has 8 counters spread over 2 blocks.  The `regs` storage
needs to be two-dimensional, indexed by block (chip) number and register
number.  (It does not need to be three-dimensional because the registers
for individual counters are intermingled within the block.)

Change the `regs` member to an array pointer that can be indexed like a
two-dimensional array to access the shadow storage for each register in
each block.  Allocate the storage in `ni_gpct_device_construct()` and
free it in `ni_gpct_device_destroy()`.  (`ni_gpct_device_construct()`
can determine the number of blocks from the `num_counters` and
`counters_per_chip` parameters.)

Add new member `num_chips` to hold the number of chips.  Use that to
check that `chip_index` value is in range in the same places that
check the register offset is in range.

Remove the `counters_per_chip` member of `struct ni_gpct_device` as it
is not needed anywhere and could be easily derived from the
`num_counters` and `num_chips` members if required.

Thanks to GitHub user "raabej" (real name unknown) for an initial
implementation of this in the out-of-tree fork of the Comedi drivers.

Signed-off-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-26 11:50:17 +01:00
Gustavo A. R. Silva
479826cc86 staging: comedi: ni_660x: fix missing break in switch statement
Add missing break statement in order to prevent the code from falling
through to the default case and return -EINVAL every time.

This bug was found thanks to the ongoing efforts to enable
-Wimplicit-fallthrough.

Fixes: aa94f28888 ("staging: comedi: ni_660x: tidy up ni_660x_set_pfi_routing()")
Cc: stable@vger.kernel.org
Signed-off-by: Gustavo A. R. Silva <gustavo@embeddedor.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-13 19:43:34 +01:00
Sandesh Kenjana Ashok
ee593133a7 staging: comedi: comedi_fops.c: Remove redundant blank line
Removed redunant blank line. Issue found by checkpatch.

Signed-off-by: Sandesh Kenjana Ashok <kas.sandesh@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-02-04 12:30:27 +01:00
Jitendra Khasdev
56eec1806f staging: comedi: Removed not necessary braces for single block
This patch is used to remove not necessary braces for single if block.

Signed-off-by: Jitendra Khasdev <jkhasdev@gmail.com>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-18 10:34:01 +01:00
Alexander Schroth
47ed91d3a2 staging: comedi: ni_pcidio: make defines uppercase
According to the Linux coding guidelines, defines should be written
in uppercase. This patch converts all define-statements in the
ni_pcidio.c file to uppercase, thus matching the coding style of the
kernel.

Signed-off-by: Alexander Schroth <alexander.schroth@fau.de>
Signed-off-by: Marco Ammon <marco.ammon@fau.de>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-15 16:08:04 +01:00
Matteo Croce
037e9edf9d staging: comedi: fix typo
Fix spelling mistake: "lenghth" -> "length"

Signed-off-by: Matteo Croce <mcroce@redhat.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-07 11:28:15 +01:00
William Mitchell Jr
8f452bbb9a staging: comedi: cb_pcimdas.c: fixed an alignment coding style issue
Fixed a coding style issue.

Signed-off-by: William Mitchell Jr <wdmjun@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2019-01-07 08:56:07 +01:00
Linus Torvalds
96d4f267e4 Remove 'type' argument from access_ok() function
Nobody has actually used the type (VERIFY_READ vs VERIFY_WRITE) argument
of the user address range verification function since we got rid of the
old racy i386-only code to walk page tables by hand.

It existed because the original 80386 would not honor the write protect
bit when in kernel mode, so you had to do COW by hand before doing any
user access.  But we haven't supported that in a long time, and these
days the 'type' argument is a purely historical artifact.

A discussion about extending 'user_access_begin()' to do the range
checking resulted this patch, because there is no way we're going to
move the old VERIFY_xyz interface to that model.  And it's best done at
the end of the merge window when I've done most of my merges, so let's
just get this done once and for all.

This patch was mostly done with a sed-script, with manual fix-ups for
the cases that weren't of the trivial 'access_ok(VERIFY_xyz' form.

There were a couple of notable cases:

 - csky still had the old "verify_area()" name as an alias.

 - the iter_iov code had magical hardcoded knowledge of the actual
   values of VERIFY_{READ,WRITE} (not that they mattered, since nothing
   really used it)

 - microblaze used the type argument for a debug printout

but other than those oddities this should be a total no-op patch.

I tried to fix up all architectures, did fairly extensive grepping for
access_ok() uses, and the changes are trivial, but I may have missed
something.  Any missed conversion should be trivially fixable, though.

Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2019-01-03 18:57:57 -08:00
Amir Mahdi Ghorbanian
3dbf37c03b Staging: comedi: cb_pcidas: fixed a spelling mistake coding style issue
Fixed a coding style issue.

Signed-off-by: Amir Mahdi Ghorbanian <indigoomega021@gmail.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-17 14:16:07 +01:00
Spencer E. Olson
f8bc1b2efa staging: comedi: change do_insn*_ioctl to allow more samples
Changes do_insn*_ioctl functions to allow for data lengths for each
comedi_insn of up to 2^16.  This patch also changes these functions to only
allocate as much memory as is necessary for each comedi_insn, rather than
allocating a fixed-sized scratch space.

In testing some user-space code for the new INSN_DEVICE_CONFIG_GET_ROUTES
facility with some newer hardware, I discovered that do_insn_ioctl and
do_insnlist_ioctl limited the amount of data that can be passed into the
kernel for insn's to a length of 256.  For some newer hardware, the number
of routes can be greater than 1000.  Working around the old limits (256)
would complicate the user-space/kernel interaction.

The new upper limit is reasonable with current memory available and does
not otherwise impact the memory footprint for any current or otherwise
typical configuration.

Signed-off-by: Spencer E. Olson <olsonse@umich.edu>
Reviewed-by: Ian Abbott <abbotti@mev.co.uk>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-12 11:37:58 +01:00
Stephen Davies
0bc5b2ba45 staging: comedi: drivers: Cleanup malformed licence identifier
This patch fixes multiple occurences of the checkpatch.pl warning:
WARNING: Missing or malformed SPDX-License-Identifier tag in line 1

NB. This is an additional patch and does not overlap the patch sent
yesterday for 8255.h. Should have sent them all together.
Newb mistake.

Cc: Ian Abbott <abbotti@mev.co.uk>
Cc: H Hartley Sweeten <hsweeten@visionengravers.com>
Signed-off-by: Stephen Davies <davo2002@tpg.com.au>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2018-12-05 09:44:05 +01:00