Skip to content

L
linux
Switch branch/tag
  1. 13 Dec, 2008 5 commits
    • Hannes Eder's avatar
      mISDN: fix sparse warning: symbol 'nskb' shadows an earlier one · bb68b1d9
      Hannes Eder authored 
      Impact: define first occurence of variable 'nskb' in inner most possible scope

Fix this sparse warning:

  drivers/isdn/mISDN/dsp_core.c:746:20: warning: symbol 'nskb' shadows an earlier one
  drivers/isdn/mISDN/dsp_core.c:634:19: originally declared here
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Acked-by: default avatarKarsten Keil <kkeil@suse.de>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bb68b1d9
    • Hannes Eder's avatar
      mISDN: un-export symbol 'plx_lock' · 65a40516
      Hannes Eder authored 
      'plx_lock' is only used within hfcmulti.c.

Fix this warning:

  drivers/isdn/hardware/mISDN/hfcmulti.c:176:1: warning: symbol 'plx_lock' shadows an earlier one
  drivers/isdn/hardware/mISDN/hfcmulti.c:175:19: originally declared here
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Acked-by: default avatarKarsten Keil <kkeil@suse.de>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      65a40516
    • Hannes Eder's avatar
      mISDN: make global symbols static or include header files · 5b834354
      Hannes Eder authored 
      The warnings fixed by including an header file for the appropriate
prototype are marked with "*", for all others the corresonponding
symbol has been made static.  This patch fixes all such issues in
mISDN.

Fix this sparse warnings:

  drivers/isdn/hardware/mISDN/hfcmulti.c:174:5: warning: symbol 'plxsd_master' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:426:1: warning: symbol 'write_fifo_regio' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:447:1: warning: symbol 'write_fifo_pcimem' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:469:1: warning: symbol 'read_fifo_regio' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:491:1: warning: symbol 'read_fifo_pcimem' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:710:1: warning: symbol 'vpm_init' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:793:1: warning: symbol 'vpm_check' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:816:1: warning: symbol 'vpm_echocan_on' was not declared. Should it be static?
  drivers/isdn/hardware/mISDN/hfcmulti.c:848:1: warning: symbol 'vpm_echocan_off' was not declared. Should it be static?
* drivers/isdn/mISDN/l1oip_codec.c:224:1: warning: symbol 'l1oip_law_to_4bit' was not declared. Should it be static?
* drivers/isdn/mISDN/l1oip_codec.c:261:1: warning: symbol 'l1oip_4bit_to_law' was not declared. Should it be static?
* drivers/isdn/mISDN/l1oip_codec.c:281:1: warning: symbol 'l1oip_alaw_to_ulaw' was not declared. Should it be static?
* drivers/isdn/mISDN/l1oip_codec.c:294:1: warning: symbol 'l1oip_ulaw_to_alaw' was not declared. Should it be static?
* drivers/isdn/mISDN/l1oip_codec.c:311:1: warning: symbol 'l1oip_4bit_free' was not declared. Should it be static?
* drivers/isdn/mISDN/l1oip_codec.c:322:1: warning: symbol 'l1oip_4bit_alloc' was not declared. Should it be static?
  drivers/isdn/mISDN/core.c:29:1: warning: symbol 'device_lock' was not declared. Should it be static?
  drivers/isdn/mISDN/core.c:34:1: warning: symbol 'bp_lock' was not declared. Should it be static?
  drivers/isdn/mISDN/core.c:196:1: warning: symbol 'mISDNInit' was not declared. Should it be static?
  drivers/isdn/mISDN/core.c:227:6: warning: symbol 'mISDN_cleanup' was not declared. Should it be static?
  drivers/isdn/mISDN/stack.c:40:1: warning: symbol 'mISDN_queue_message' was not declared. Should it be static?
* drivers/isdn/mISDN/layer1.c:388:1: warning: symbol 'l1_init' was not declared. Should it be static?
* drivers/isdn/mISDN/layer1.c:400:1: warning: symbol 'l1_cleanup' was not declared. Should it be static?
  drivers/isdn/mISDN/layer2.c:469:1: warning: symbol 'iframe_error' was not declared. Should it be static?
  drivers/isdn/mISDN/layer2.c:487:1: warning: symbol 'super_error' was not declared. Should it be static?
  drivers/isdn/mISDN/layer2.c:496:1: warning: symbol 'unnum_error' was not declared. Should it be static?
  drivers/isdn/mISDN/layer2.c:509:1: warning: symbol 'UI_error' was not declared. Should it be static?
  drivers/isdn/mISDN/layer2.c:522:1: warning: symbol 'FRMR_error' was not declared. Should it be static?
  drivers/isdn/mISDN/layer2.c:1069:1: warning: symbol 'enquiry_cr' was not declared. Should it be static?
* drivers/isdn/mISDN/layer2.c:2196:1: warning: symbol 'Isdnl2_Init' was not declared. Should it be static?
* drivers/isdn/mISDN/layer2.c:2210:1: warning: symbol 'Isdnl2_cleanup' was not declared. Should it be static?
  drivers/isdn/mISDN/tei.c:397:1: warning: symbol 'random_ri' was not declared. Should it be static?
* drivers/isdn/mISDN/timerdev.c:277:1: warning: symbol 'mISDN_inittimer' was not declared. Should it be static?
* drivers/isdn/mISDN/timerdev.c:288:6: warning: symbol 'mISDN_timer_cleanup' was not declared. Should it be static?
  drivers/isdn/mISDN/dsp_core.c:164:12: warning: symbol 'mISDN_dsp_revision' was not declared. Should it be static?
  drivers/isdn/mISDN/dsp_cmx.c:1543:5: warning: symbol 'samplecount' was not declared. Should it be static?
  drivers/isdn/mISDN/dsp_cmx.c:1546:5: warning: symbol 'dsp_start_jiffies' was not declared. Should it be static?
  drivers/isdn/mISDN/dsp_cmx.c:1547:16: warning: symbol 'dsp_start_tv' was not declared. Should it be static?
  drivers/isdn/mISDN/dsp_tones.c:239:3: warning: symbol 'pattern' was not declared. Should it be static?
  drivers/isdn/mISDN/dsp_audio.c:33:4: warning: symbol 'dsp_audio_ulaw_to_alaw' was not declared. Should it be static?
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Acked-by: default avatarKarsten Keil <kkeil@suse.de>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      5b834354
    • Hannes Eder's avatar
      mISDN: consistently define 'debug' as '*u_int' · dfa96ec1
      Hannes Eder authored 
      Impact: change data type for variable 'debug' from *int to *u_int,
same for the argument type of mISDN_inittimer

In "core.h" mISDN_inittimer is declared with the argument type "*u_int", make
the definition in "timerdev.c" match this.

This fixes also this warnings:

  drivers/isdn/mISDN/layer1.c:391:8: warning: incorrect type in assignment (different signedness)
  drivers/isdn/mISDN/layer1.c:391:8:    expected int *static [toplevel] debug
  drivers/isdn/mISDN/layer1.c:391:8:    got unsigned int [usertype] *deb
  drivers/isdn/mISDN/layer2.c:2200:8: warning: incorrect type in assignment (different signedness)
  drivers/isdn/mISDN/layer2.c:2200:8:    expected int *static [toplevel] debug
  drivers/isdn/mISDN/layer2.c:2200:8:    got unsigned int [usertype] *deb
  drivers/isdn/mISDN/socket.c:769:8: warning: incorrect type in assignment (different signedness)
  drivers/isdn/mISDN/socket.c:769:8:    expected int *static [toplevel] debug
  drivers/isdn/mISDN/socket.c:769:8:    got unsigned int [usertype] *deb
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Acked-by: default avatarKarsten Keil <kkeil@suse.de>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      dfa96ec1
    • Hannes Eder's avatar
      mISDN: use NULL pointer instead of plain integer · bcf91745
      Hannes Eder authored 
      Fix more than 100 (all remaining in mISDN) sparse warnings:

  drivers/isdn/hardware/mISDN/hfcmulti.c:***:**: warning: Using plain integer as NULL pointer
  drivers/isdn/mISDN/dsp_tones.c:***:**: warning: Using plain integer as NULL pointer
  drivers/isdn/mISDN/dsp_pipeline.c:***:**: warning: Using plain integer as NULL pointer
Signed-off-by: default avatarHannes Eder <hannes@hanneseder.net>
Acked-by: default avatarKarsten Keil <kkeil@suse.de>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      bcf91745
  3. 12 Dec, 2008 4 commits
  5. 11 Dec, 2008 10 commits
  7. 10 Dec, 2008 15 commits
  9. 09 Dec, 2008 4 commits
  11. 08 Dec, 2008 2 commits
    • Gerrit Renker's avatar
      dccp ccid-2: Phase out the use of boolean Ack Vector sysctl · 6fdd34d4
      Gerrit Renker authored 
      This removes the use of the sysctl and the minisock variable for the Send Ack
Vector feature, as it now is handled fully dynamically via feature negotiation
(i.e. when CCID-2 is enabled, Ack Vectors are automatically enabled as per
 RFC 4341, 4.).

Using a sysctl in parallel to this implementation would open the door to
crashes, since much of the code relies on tests of the boolean minisock /
sysctl variable. Thus, this patch replaces all tests of type

	if (dccp_msk(sk)->dccpms_send_ack_vector)
		/* ... */
with
	if (dp->dccps_hc_rx_ackvec != NULL)
		/* ... */

The dccps_hc_rx_ackvec is allocated by the dccp_hdlr_ackvec() when feature
negotiation concluded that Ack Vectors are to be used on the half-connection.
Otherwise, it is NULL (due to dccp_init_sock/dccp_create_openreq_child),
so that the test is a valid one.

The activation handler for Ack Vectors is called as soon as the feature
negotiation has concluded at the
 * server when the Ack marking the transition RESPOND => OPEN arrives;
 * client after it has sent its ACK, marking the transition REQUEST => PARTOPEN.

Adding the sequence number of the Response packet to the Ack Vector has been
removed, since
 (a) connection establishment implies that the Response has been received;
 (b) the CCIDs only look at packets received in the (PART)OPEN state, i.e.
     this entry will always be ignored;
 (c) it can not be used for anything useful - to detect loss for instance, only
     packets received after the loss can serve as pseudo-dupacks.

There was a FIXME to change the error code when dccp_ackvec_add() fails.
I removed this after finding out that:
 * the check whether ackno < ISN is already made earlier,
 * this Response is likely the 1st packet with an Ackno that the client gets,
 * so when dccp_ackvec_add() fails, the reason is likely not a packet error.
Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: default avatarIan McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      6fdd34d4
    • Gerrit Renker's avatar
      dccp: Remove manual influence on NDP Count feature · 4098dce5
      Gerrit Renker authored 
      Updating the NDP count feature is handled automatically now:
 * for CCID-2 it is disabled, since the code does not use NDP counts;
 * for CCID-3 it is enabled, as NDP counts are used to determine loss lengths.

Allowing the user to change NDP values leads to unpredictable and failing
behaviour, since it is then possible to disable NDP counts even when they
are needed (e.g. in CCID-3).

This means that only those user settings are sensible that agree with the
values for Send NDP Count implied by the choice of CCID. But those settings
are already activated by the feature negotiation (CCID dependency tracking),
hence this form of support is redundant.

At startup the initialisation of the NDP count feature uses the default
value of 0, which is done implicitly by the zeroing-out of the socket when
it is allocated. If the choice of CCID or feature negotiation enables NDP
count, this will then be updated via the NDP activation handler.
Signed-off-by: default avatarGerrit Renker <gerrit@erg.abdn.ac.uk>
Acked-by: default avatarIan McDonald <ian.mcdonald@jandi.co.nz>
Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4098dce5
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7