`struct timeval` has been removed from the kernel interface in 5.0 as
part of fixing the 2038 problem. ktime_t is the preferred kernel time
interface now.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
There are not any major distributions that are still supporting kernels
older than 2.6.27 so we can remove many typedefs. The primary motivator
for this change is that kernel 5.0 is dropping support for timeval and
it would be ideal if the in-kernel time representation can
standardize on ktime_t, but 2.6.18 did not support the ktime
interface that was needed.
Signed-off-by: Shaun Ruffell <sruffell@sruffell.net>
Upstream kernel 4.14, in commit (686fef928bba6b "timer: Prepare to change timer
callback argument type") [1], introduced the timer_setup interface to replace
the init_timer/setup_timer interfaces. The primary change is that the timer
callback functions now follow the standard kernel pattern where the structure
the callback sits in is passed to the callback instead of storing a pointer to
an unassociated data type.
The setup_timer functions were removed in upstream kernel v4.15, and therefore
this change is needed in order to compile DAHDI for kernels >= 4.15.
This change follows the same strategy that was done in the kernel to while the
existing users of setup_timer were migrated to the new interface.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=686fef928bba6b
The upstream 4.11 kernel, in commit (10383aea2f445bce9b2a2b308def08134b438c8e
"kref: Implement 'struct kref' using refcount_t"), changed refcount type on kref
objects. We now need to use refcount_read to read them.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
The number of subunits per XPD (which is not trivial in BRI) has been
accidentally left out in a previous commit.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
The new FXS chip supports two ports for each chip and hence we once
again need to look at hardware differently.
Struct unit_description includes information about all chips/port in a
specific module.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
re-organize calls so worker_reset() isn't called twice
(was called from xbus_disconnect() and worker_destroy())
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* Maintain a "shutting_down" flag per-xbus
* Use it to prevent xbus dereferencing (via xbus_get()/xbus_put())
during an xbus shutdown.
* Also, remove xbus from global array earlier.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
waitfor_xpds xbus sysfs file should not take an xbus refcount:
* It is called from sysfs which maintain its own device refcount.
* If put_xbus() calls xbus_destroy() than down the call chain it will
try to release an object that is held by sysfs.
* This will create a deadlock.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Some architectures, like arm, do not automatically pull in the definitions for
kzalloc and friends. This allows DAHDI to build on those platforms.
Originally reported to the asterisk-users mailing list here
http://lists.digium.com/pipermail/asterisk-users/2014-February/282338.html
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Signed-off-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* It's currently harmless (just re-run the pre/post XPD registrations)
* But it's cleaner this way (as with xbus_register_dahdi_device())
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
* dahdi_registration writes multiple times to:
/sys/bus/astribanks/devices/*/*/span
* In some race cases this resulted in corruption and eventual kernel
panic.
* Until migration to "assigned-spans" is complete:
- Accept and ignore multiple "dahdi registrations" from user-space.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Commit 74e949c33a exported the module
variable dahdi.auto_assigned_spans. However this is not a good name.
This commit reverts the export and replaces it with a new function to
get the value of the variable.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* Set it to 0 by default (as we use dahdi.auto_assign_spans now)
* Make it readonly (no runtime changes)
* Warn during startup if it was forced to 1
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
Instead, use the inverse of dahdi.auto_assign_spans value.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Russ Meyerriecks <rmeyerriecks@digium.com>
* If userspace would run
modprobe xpp_usb && cat /sys/bus/astribanks/devices/xbus-00/waitfor_xpds
it would return immediately rather than wait for the Astribank to
initialize.
* We sometimes managed to read before getting the reply from the
astribank.
* Now we don't trust unit count at such an early stage.
* Instread we wait for the Astribank to reach a stable state (READY or FAIL)
before finish waiting for this astribank.
Internal-Issue-ID: Xorcom-1502
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Don't use create_proc_read_entry() as that is deprecated, but rather use
proc_create_data() and seq_file instead.
This is needed to compile against Linux 3.10.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
[tzafrir.cohen@xorcom.com: fixed passing /proc/xpp/XPD/summary xbus number]
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Cc: Russ Meyerriecks <rmeyerriecks@digium.com>
Cc: Oron Peled <oron.peled@xorcom.com>
This patch removes support for kernel versions < 2.6.18, as those are
not actively supported in any major Linux distribution (except RHEL4,
which is in the "extended" support level of the product life cycle).
This removes much of the more #ifdef-rich parts of the code.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10472 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Manually place EXPORT_SYMBOL() after symbols (or at end of functions).
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10431 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* If dahdi_register_device() failed, not all resources were freed.
When dahdi_unregister_device() was called later (during driver
removal) a panic was caused.
* Add proper error handling for possible failures in
xbus_register_dahdi_device():
- new xbus_free_ddev() safely free an xbus->ddev
- This is called from all failures points.
- It is also called from xbus_unregister_dahdi_device()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10410 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* A bug was introduced during migration to dahdi_device code:
http://svnview.digium.com/svn/dahdi?view=rev&rev=10273
* Marking XPDs as non-functional (card_present=0, XPD_STATE_NOHW)
was moved from xbus_request_removal() into xpd_dahdi_preunregister()
* As a result, unregistering an Astribank, made it non-functional
so trying to re-register it later caused errors (e.g: "Cannot open"
error message from xpp_open())
* This fix move XPD deactivation into the proper location (during
xbus_deactivate()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10409 a0bf4364-ded3-4de4-8d8a-66a801d63aff
module_put() that was added while developing the sysfs code. The real
module_get()/module_put() pair were already removed at the time of
developing code for this branch. It was only triggered when using a
system with more than 32 (MAX_BUSES) Astribanks.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10383 a0bf4364-ded3-4de4-8d8a-66a801d63aff
A length of 1000 commands is not enough is some cases with CAS.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10341 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This restores a somewhat limited functionality of the "span"
write interface in the SysFS node of the span, broken by the
pinned-spans code.
* PROBLEM: dahdi-linux pinned-spans should work with existing dahdi-tools
specifically the dahdi_registration tool.
* As a result, we should still be able to control dahdi registration
order. However, registration is now in complete devices and not spans
* Restored dahdi_autoreg=[0/1] xpp module parameter:
- It now refers to complete astribanks and not individual spans
* The xpp module sysfs "span" attribute:
- Implemented write method (for dahdi_registration tool)
- The first write of [1/0] to this attribute, registers/unregisters
the complete astribank
- Further writes are ignored (with DBG messages)
* Also, implemented new xbus_is_registered() function
* Once the new dahdi-tools are merged, we should turn deprecation
messages from DBG() to NOTICE()
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10334 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* With pinned-spans all spans are registered to dahdi with the
device (and assigned later)
* So this parameter cannot function anymore
* Also remove the (now) empty xpd_post_init() function.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10284 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* Otherwise, a failed unit initialization (e.g: when init_card_?_?? fails)
causes a panic
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10282 a0bf4364-ded3-4de4-8d8a-66a801d63aff
This exposes dahdi devices in sysfs and also exposes attributes that
will allow user space to control the registration order in spans. This
facilitates loading drivers out of order yet keeping consistent
span/channel numbering, which in turn will eventually allow the
blacklist for DAHDI drivers to be removed. The default behavior,
controlled with the auto_register module parameter on dahdi is to number
the spans / channels in order like is currently done. So this change
does not introduce any new behavior by default.
* Writing (anything) to this attribute returns the span to its
unassigned state
* Fix dahdi_chan_unreg() echocan refcount
* Add safeguard against duplicate unassignment to _dahdi_unregister_span()
* Remove the span from device_node list, only in dahdi_unregister_device()
and not in dahdi_unregister_span()
* Free allocated span->span_device in span_sysfs_remove()
[is it safe?, didn't cause problem so far...]
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
dahdi: Add "hardware_id" dahdi_device attribute.
- The "hardware_id" does not change with device location (e.g: when a PCI
card is moved from one slot to another).
- Not all devices have this attribute. It is legal for it to be NULL (that
is the default for all low-level drivers that do not set it explicitly).
- When "hardware_id" is NULL, the sysfs attribute value is "\n"
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10275 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Increasingly, spans are implemented by devices that support more than a
single span. Introduce a 'struct dahdi_device' object which explicitly
contains multiple spans. This will allow a cleaner representation of
spans and devices in sysfs since order of arrival will not determine the
layout of the devices. This also gives the core of dahdi a way to know
the relationship between spans.
This generalizes similar concepts that were previously xpp specific. The
conversion of the xpp code was almost entirely done by Oron and Tzafrir.
Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10273 a0bf4364-ded3-4de4-8d8a-66a801d63aff
Required by CAS in latest (2.5) DAHDI versions.
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10055 a0bf4364-ded3-4de4-8d8a-66a801d63aff
In some cases the hardware echo canceller cannot be used. Mostly related to
an FXO module.
* FXO module if the first module is BRI or PRI
* FXS module if the Astribank has another FXO, no PRI/BRI, and is a sync
slave.
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-By: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10019 a0bf4364-ded3-4de4-8d8a-66a801d63aff
* xpd_echo (card_echo.c) - a module to handle an Astribank hardware echo
canceller module.
* All other XPDs are now of type 'telephony_device'. Only a telephony device
XPD provides a span to register.
* The EC module will typically show up as XPD-40 and will always show up as
Unregistered in 'dahdi_hardware -v'
Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9993 a0bf4364-ded3-4de4-8d8a-66a801d63aff
