Commit Graph

9 Commits

Author SHA1 Message Date
Oron Peled
09e46f2213 Extra debugging aids and messages
* Added dahdi_dev_dbg() macro to print when we don't (yet)
  have a span number.
* Added a new debug category: DAHDI_DBG_ASSIGN
* Made sure error return code paths prints helpfull messages
* Promote error messages from INFO to NOTICE
* Change some errno values from EINVAL to EFAULT (internal
  errors not caused by user input)

Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Acked-by Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10328 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-11-07 17:48:00 +00:00
Oron Peled
3fc23b4465 added 'basechan' and 'channels' attributes to spans
* So we can:
   - Generate 'pinned-spans.conf' from existing state
   - Run dahdi_cfg from udev (on specific span + its channels)

Signed-off-by: Oron Peled <oron.peled@xorcom.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10286 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-10-26 19:08:33 +00:00
Shaun Ruffell
f9c52bb271 dahdi: Allow 'spantype' to be changed before span assignement via sysfs.
For some boards, the linemode (E1/T1/J1) is software selectable but
needs to be configured before the spans were historically registered
since the line mode determines the channel count available on the span.

This change exports a "spantype" attribute from the dahdi_device that
can be used to set E1/T1/J1 before the spans are assigned. When
userspace writes to this attribute (in a <span offset>:<span type
string> format), and if the board driver has implemented a set_spantype
function in it's dahdi_span_ops, then the board driver can optionally
change it's mode before registration.

Also part of this change is breaking out the raw data structure
initialization of the spans / channels via the dahdi_init_device_spans
function since the board drivers may need to reallocate channels / spans
as part of this callback. For example, changing from T1 to E1 mode will
require allocating 7 new channels.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10277 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-10-26 19:01:19 +00:00
Shaun Ruffell
8d23f878d4 dahdi: Remove dahdi_span.irq and move dahdi_span.irqmisses into dahdi_device.
'irqmisses' is more a function of the device and there are better ways
to get to IRQ for a device than storing it in any DAHDI structures.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10276 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-10-26 19:00:28 +00:00
Shaun Ruffell
a6824019fb dahdi: Expose dahdi devices in sysfs.
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
2011-10-26 18:59:20 +00:00
Oron Peled
2794bb4937 dahdi: Expose spans in sysfs.
This change will facilitate creating rules that will allow spans and channels
to be accessed by named device files instead of by numbers.

Signed-off-by: Oron Peled <oron.peled@xorcom.com>
Signed-off-by: Shaun Ruffell <sruffell@digium.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@10274 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-10-26 18:58:50 +00:00
Shaun Ruffell
d43e2d3ade dahdi: Do not rebuild dahdi-base.c when only updating the version.
This moves the version string into dahdi-version.c that is then linked into
dahdi-base.c and dahdi-sysfs.c.  This speeds builds on slow computers since
dahdi-base.c and dahdi-sysfs.c does not need to be rebuilt if only the version
string is changing.

Signed-off-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>

git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9777 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-02-28 14:19:09 +00:00
Tzafrir Cohen
cd595df1c3 dahdi-sysfs: include slab.h for newer kernels
git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9633 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-01-16 21:12:20 +00:00
Tzafrir Cohen
69f3c96690 Refactor SysFS code to dahdi-sysfs.c
* Refactor SysFS and device-related code to drivers/dahdi/dahdi-sysfs.c .
* Move common headers to drivers/dahdi/dahdi.h .

This commit merely moves existing code and should have no functional
change.

Signed-off-by: Tzafrir Cohen <tzafrir.cohen@xorcom.com>
Acked-by: Shaun Ruffell <sruffell@digium.com>
Acked-by: Oron Peled <oron.peled@xorcom.com>


git-svn-id: http://svn.asterisk.org/svn/dahdi/linux/trunk@9628 a0bf4364-ded3-4de4-8d8a-66a801d63aff
2011-01-16 14:18:18 +00:00