Skip to content

R
raspberrypi-kernel

openeuler / raspberrypi-kernel

通知 13
Star 1
Fork 0
R
raspberrypi-kernel
切换分支/标签
  1. 16 3月, 2010 2 次提交
    • I
      i4l: change magic numbers in Eicon DIVA ISDN driver to symbolic names · 255f5c32
      由 Ian Munsie 提交于 
      Replace references to the '20' magic number found throughout the Eicon
ISDN driver for the length of the station_id field in the T30_INFO struct
with the T30_MAX_STATION_ID_LENGTH symbolic constant.
Signed-off-by: NIan Munsie <imunsie@au.ibm.com>
Cc: Armin Schindler <mac@melware.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Stoyan Gaydarov <sgayda2@uiuc.edu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      255f5c32
    • I
      i4l: silence compiler warnings for array access in Eicon DIVA ISDN driver · 8b4017d8
      由 Ian Munsie 提交于 
      When compiling this driver, the compiler throws the following warnings:

drivers/isdn/hardware/eicon/message.c:8426: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8427: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8434: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8435: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8436: warning: array subscript is above array bounds
drivers/isdn/hardware/eicon/message.c:8447: warning: array subscript is above array bounds

This arises from the particular semantics the driver is using to write to
the nlc array (static byte[256]).  The array has a length in byte 0
followed by a T30_INFO struct starting at byte 1.

The T30_INFO struct has a number of variable length strings after the
station_id entry, which cannot be explicitly defined in the struct and the
driver accesses them with an array index to station_id beyond the length
of station_id.

This patch merely changes the semantics that the driver uses to access the
entries after the station_id entry to use the original 256 byte nlc array
taking the offset and length of the station_id entry to calculate where to
write in the array, thereby silencing the warning.
Signed-off-by: NIan Munsie <imunsie@au.ibm.com>
Cc: Armin Schindler <mac@melware.de>
Cc: Karsten Keil <isdn@linux-pingi.de>
Cc: Stoyan Gaydarov <sgayda2@uiuc.edu>
Signed-off-by: NAndrew Morton <akpm@linux-foundation.org>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8b4017d8
  3. 04 2月, 2010 3 次提交
  5. 14 1月, 2010 1 次提交
  7. 04 1月, 2010 1 次提交
  9. 08 12月, 2009 1 次提交
  11. 04 12月, 2009 1 次提交
  13. 29 11月, 2009 1 次提交
    • D
      pcmcia: rework the irq_req_t typedef · 5fa9167a
      由 Dominik Brodowski 提交于 
      Most of the irq_req_t typedef'd struct can be re-worked quite
easily:

(1) IRQInfo2 was unused in any case, so drop it.

(2) IRQInfo1 was used write-only, so drop it.

(3) Instance (private data to be passed to the IRQ handler):
	Most PCMCIA drivers using pcmcia_request_irq() to actually
	register an IRQ handler set the "dev_id" to the same pointer
	as the "priv" pointer in struct pcmcia_device. Modify the two
	exceptions (ipwireless, ibmtr_cs) to also work this waym and
	set the IRQ handler's "dev_id" to p_dev->priv unconditionally.

(4) Handler is to be of type irq_handler_t.

(5) Handler != NULL already tells whether an IRQ handler is present.
	Therefore, we do not need the IRQ_HANDLER_PRESENT flag in
	irq_req_t.Attributes.

CC: netdev@vger.kernel.org
CC: linux-bluetooth@vger.kernel.org
CC: linux-ide@vger.kernel.org
CC: linux-wireless@vger.kernel.org
CC: linux-scsi@vger.kernel.org
CC: alsa-devel@alsa-project.org
CC: Jaroslav Kysela <perex@perex.cz>
CC: Jiri Kosina <jkosina@suse.cz>
CC: Karsten Keil <isdn@linux-pingi.de>
for the Bluetooth parts: Acked-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: NDominik Brodowski <linux@dominikbrodowski.net>
      5fa9167a
  15. 16 11月, 2009 1 次提交
  17. 11 11月, 2009 1 次提交
  19. 09 11月, 2009 1 次提交
  21. 05 11月, 2009 2 次提交
  23. 29 9月, 2009 1 次提交
    • R
      isdn: fix netjet/isdnhdlc build errors · 8823ad31
      由 Randy Dunlap 提交于 
      Commit cb3824ba didn't fix this problem.

Fix build errors in netjet, using isdnhdlc module:

drivers/built-in.o: In function `mode_tiger':
netjet.c:(.text+0x1ca0c7): undefined reference to `isdnhdlc_rcv_init'
netjet.c:(.text+0x1ca0d4): undefined reference to `isdnhdlc_out_init'
drivers/built-in.o: In function `fill_dma':
netjet.c:(.text+0x1ca2bd): undefined reference to `isdnhdlc_encode'
drivers/built-in.o: In function `read_dma':
netjet.c:(.text+0x1ca614): undefined reference to `isdnhdlc_decode'
drivers/built-in.o: In function `nj_irq':
netjet.c:(.text+0x1cb07a): undefined reference to `isdnhdlc_encode'

drivers/built-in.o: In function `isdnhdlc_decode':
(.text+0x1c2088): undefined reference to `crc_ccitt_table'
drivers/built-in.o: In function `isdnhdlc_encode':
(.text+0x1c2339): undefined reference to `crc_ccitt_table'
Signed-off-by: NRandy Dunlap <randy.dunlap@oracle.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      8823ad31
  25. 27 7月, 2009 2 次提交
  27. 26 7月, 2009 8 次提交
  29. 12 6月, 2009 1 次提交
  31. 08 6月, 2009 1 次提交
  33. 25 5月, 2009 8 次提交
  35. 31 3月, 2009 1 次提交
    • A
      proc 2/2: remove struct proc_dir_entry::owner · 99b76233
      由 Alexey Dobriyan 提交于 
      Setting ->owner as done currently (pde->owner = THIS_MODULE) is racy
as correctly noted at bug #12454. Someone can lookup entry with NULL
->owner, thus not pinning enything, and release it later resulting
in module refcount underflow.

We can keep ->owner and supply it at registration time like ->proc_fops
and ->data.

But this leaves ->owner as easy-manipulative field (just one C assignment)
and somebody will forget to unpin previous/pin current module when
switching ->owner. ->proc_fops is declared as "const" which should give
some thoughts.

->read_proc/->write_proc were just fixed to not require ->owner for
protection.

rmmod'ed directories will be empty and return "." and ".." -- no harm.
And directories with tricky enough readdir and lookup shouldn't be modular.
We definitely don't want such modular code.

Removing ->owner will also make PDE smaller.

So, let's nuke it.

Kudos to Jeff Layton for reminding about this, let's say, oversight.

http://bugzilla.kernel.org/show_bug.cgi?id=12454Signed-off-by: NAlexey Dobriyan <adobriyan@gmail.com>
      99b76233
  37. 27 2月, 2009 2 次提交
    • H
      drivers/isdn/hardware/eicon: fix sparse warnings: Should it be static? · 465e9850
      由 Hannes Eder 提交于 
      Impact: Make symbols static.

Fix this sparse warnings:
  drivers/isdn/hardware/eicon/message.c:1197:6: warning: symbol 'connect_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1414:6: warning: symbol 'connect_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1570:6: warning: symbol 'connect_a_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1576:6: warning: symbol 'disconnect_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1631:6: warning: symbol 'disconnect_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1658:6: warning: symbol 'listen_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1707:6: warning: symbol 'info_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1816:6: warning: symbol 'info_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1822:6: warning: symbol 'alert_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:1852:6: warning: symbol 'facility_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:2602:6: warning: symbol 'facility_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:2608:6: warning: symbol 'connect_b3_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:2842:6: warning: symbol 'connect_b3_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:2957:6: warning: symbol 'connect_b3_a_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:2977:6: warning: symbol 'disconnect_b3_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3033:6: warning: symbol 'disconnect_b3_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3089:6: warning: symbol 'data_b3_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3166:6: warning: symbol 'data_b3_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3199:6: warning: symbol 'reset_b3_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3240:6: warning: symbol 'reset_b3_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3264:6: warning: symbol 'connect_b3_t90_a_res' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:3298:6: warning: symbol 'select_b_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:8692:6: warning: symbol 'sig_req' was not declared. Should it be static?
  drivers/isdn/hardware/eicon/message.c:8792:6: warning: symbol 'send_data' was not declared. Should it be static?
Signed-off-by: NHannes Eder <hannes@hanneseder.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      465e9850
    • H
      drivers/isdn/hardware/icon: fix sparse warning: cast truncates bits · 215a9c78
      由 Hannes Eder 提交于 
      Fix this sparse warning:
  drivers/isdn/hardware/eicon/debug.c:1201:32: warning: cast truncates bits from constant value (1000 becomes 0)
Signed-off-by: NHannes Eder <hannes@hanneseder.net>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      215a9c78
  39. 16 2月, 2009 1 次提交