Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
接近 2 年 前同步成功

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 29 1月, 2018 1 次提交
  3. 13 12月, 2017 1 次提交
  5. 30 11月, 2017 1 次提交
    • M
      media: drivers: remove "/**" from non-kernel-doc comments · cba862dc
      由 Mauro Carvalho Chehab 提交于 
      Several comments are wrongly tagged as kernel-doc, causing
those warnings:

  drivers/media/rc/st_rc.c:98: warning: No description found for parameter 'irq'
  drivers/media/rc/st_rc.c:98: warning: No description found for parameter 'data'
  drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description found for parameter 'solo_dev'
  drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description found for parameter 'ch'
  drivers/media/pci/solo6x10/solo6x10-enc.c:183: warning: No description found for parameter 'qp'
  drivers/media/usb/pwc/pwc-dec23.c:652: warning: Cannot understand  *
   on line 652 - I thought it was a doc line
  drivers/media/usb/dvb-usb/cinergyT2-fe.c:40: warning: No description found for parameter 'op'
  drivers/media/usb/dvb-usb/friio-fe.c:301: warning: Cannot understand  * (reg, val) commad list to initialize this module.
   on line 301 - I thought it was a doc line
  drivers/media/rc/streamzap.c:201: warning: No description found for parameter 'urb'
  drivers/media/rc/streamzap.c:333: warning: No description found for parameter 'intf'
  drivers/media/rc/streamzap.c:333: warning: No description found for parameter 'id'
  drivers/media/rc/streamzap.c:464: warning: No description found for parameter 'interface'
  drivers/media/i2c/ov5647.c:432: warning: Cannot understand  * @short Subdev core operations registration
   on line 432 - I thought it was a doc line
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for parameter 'd'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for parameter 'addr'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for parameter 'wbuf'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for parameter 'wlen'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for parameter 'rbuf'
  drivers/media/usb/dvb-usb/friio.c:35: warning: No description found for parameter 'rlen'
  drivers/media/platform/vim2m.c:350: warning: No description found for parameter 'priv'
  drivers/media/dvb-frontends/tua6100.c:34: warning: cannot understand function prototype: 'struct tua6100_priv '
  drivers/media/platform/sti/hva/hva-h264.c:140: warning: cannot understand function prototype: 'struct hva_h264_stereo_video_sei '
  drivers/media/platform/sti/hva/hva-h264.c:150: warning: Cannot understand  * @frame_width: width in pixels of the buffer containing the input frame
   on line 150 - I thought it was a doc line
  drivers/media/platform/sti/hva/hva-h264.c:356: warning: Cannot understand  * @ slice_size: slice size
   on line 356 - I thought it was a doc line
  drivers/media/platform/sti/hva/hva-h264.c:369: warning: Cannot understand  * @ bitstream_size: bitstream size
   on line 369 - I thought it was a doc line
  drivers/media/platform/sti/hva/hva-h264.c:395: warning: Cannot understand  * @seq_info:  sequence information buffer
   on line 395 - I thought it was a doc line
  drivers/media/dvb-frontends/sp887x.c:137: warning: No description found for parameter 'fe'
  drivers/media/dvb-frontends/sp887x.c:137: warning: No description found for parameter 'fw'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for parameter 'n'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for parameter 'd'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for parameter 'quotient_i'
  drivers/media/dvb-frontends/sp887x.c:287: warning: No description found for parameter 'quotient_f'
  drivers/media/usb/ttusb-budget/dvb-ttusb-budget.c:83: warning: cannot understand function prototype: 'struct ttusb '
  drivers/media/platform/sh_veu.c:277: warning: No description found for parameter 'priv'
  drivers/media/dvb-frontends/zl10036.c:33: warning: cannot understand function prototype: 'int zl10036_debug; '
  drivers/media/dvb-frontends/zl10036.c:179: warning: No description found for parameter 'state'
  drivers/media/dvb-frontends/zl10036.c:179: warning: No description found for parameter 'frequency'
  drivers/media/platform/rcar_fdp1.c:1139: warning: No description found for parameter 'priv'
  drivers/media/platform/ti-vpe/vpe.c:933: warning: No description found for parameter 'priv'
  drivers/media/usb/gspca/ov519.c:36: warning: No description found for parameter 'fmt'
  drivers/media/usb/dvb-usb/dib0700_devices.c:3367: warning: No description found for parameter 'adap'
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      cba862dc
  7. 07 11月, 2017 1 次提交
    • A
      media: dib0700: fix invalid dvb_detach argument · eb0c1994
      由 Andrey Konovalov 提交于 
      dvb_detach(arg) calls symbol_put_addr(arg), where arg should be a pointer
to a function. Right now a pointer to state->dib7000p_ops is passed to
dvb_detach(), which causes a BUG() in symbol_put_addr() as discovered by
syzkaller. Pass state->dib7000p_ops.set_wbd_ref instead.

------------[ cut here ]------------
kernel BUG at kernel/module.c:1081!
invalid opcode: 0000 [#1] PREEMPT SMP KASAN
Modules linked in:
CPU: 1 PID: 1151 Comm: kworker/1:1 Tainted: G        W
4.14.0-rc1-42251-gebb2c243 #224
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
Workqueue: usb_hub_wq hub_event
task: ffff88006a336300 task.stack: ffff88006a7c8000
RIP: 0010:symbol_put_addr+0x54/0x60 kernel/module.c:1083
RSP: 0018:ffff88006a7ce210 EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880062a8d190 RCX: 0000000000000000
RDX: dffffc0000000020 RSI: ffffffff85876d60 RDI: ffff880062a8d190
RBP: ffff88006a7ce218 R08: 1ffff1000d4f9c12 R09: 1ffff1000d4f9ae4
R10: 1ffff1000d4f9bed R11: 0000000000000000 R12: ffff880062a8d180
R13: 00000000ffffffed R14: ffff880062a8d190 R15: ffff88006947c000
FS:  0000000000000000(0000) GS:ffff88006c900000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 00007f6416532000 CR3: 00000000632f5000 CR4: 00000000000006e0
Call Trace:
 stk7070p_frontend_attach+0x515/0x610
drivers/media/usb/dvb-usb/dib0700_devices.c:1013
 dvb_usb_adapter_frontend_init+0x32b/0x660
drivers/media/usb/dvb-usb/dvb-usb-dvb.c:286
 dvb_usb_adapter_init drivers/media/usb/dvb-usb/dvb-usb-init.c:86
 dvb_usb_init drivers/media/usb/dvb-usb/dvb-usb-init.c:162
 dvb_usb_device_init+0xf70/0x17f0 drivers/media/usb/dvb-usb/dvb-usb-init.c:277
 dib0700_probe+0x171/0x5a0 drivers/media/usb/dvb-usb/dib0700_core.c:886
 usb_probe_interface+0x35d/0x8e0 drivers/usb/core/driver.c:361
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_set_configuration+0x104e/0x1870 drivers/usb/core/message.c:1932
 generic_probe+0x73/0xe0 drivers/usb/core/generic.c:174
 usb_probe_device+0xaf/0xe0 drivers/usb/core/driver.c:266
 really_probe drivers/base/dd.c:413
 driver_probe_device+0x610/0xa00 drivers/base/dd.c:557
 __device_attach_driver+0x230/0x290 drivers/base/dd.c:653
 bus_for_each_drv+0x161/0x210 drivers/base/bus.c:463
 __device_attach+0x26e/0x3d0 drivers/base/dd.c:710
 device_initial_probe+0x1f/0x30 drivers/base/dd.c:757
 bus_probe_device+0x1eb/0x290 drivers/base/bus.c:523
 device_add+0xd0b/0x1660 drivers/base/core.c:1835
 usb_new_device+0x7b8/0x1020 drivers/usb/core/hub.c:2457
 hub_port_connect drivers/usb/core/hub.c:4903
 hub_port_connect_change drivers/usb/core/hub.c:5009
 port_event drivers/usb/core/hub.c:5115
 hub_event+0x194d/0x3740 drivers/usb/core/hub.c:5195
 process_one_work+0xc7f/0x1db0 kernel/workqueue.c:2119
 worker_thread+0x221/0x1850 kernel/workqueue.c:2253
 kthread+0x3a1/0x470 kernel/kthread.c:231
 ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:431
Code: ff ff 48 85 c0 74 24 48 89 c7 e8 48 ea ff ff bf 01 00 00 00 e8
de 20 e3 ff 65 8b 05 b7 2f c2 7e 85 c0 75 c9 e8 f9 0b c1 ff eb c2 <0f>
0b 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00 48 b8 00 00
RIP: symbol_put_addr+0x54/0x60 RSP: ffff88006a7ce210
---[ end trace b75b357739e7e116 ]---
Signed-off-by: NAndrey Konovalov <andreyknvl@google.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      eb0c1994
  9. 20 8月, 2017 1 次提交
  11. 19 5月, 2017 1 次提交
    • M
      [media] media drivers: annotate fall-through · 06eeefe8
      由 Mauro Carvalho Chehab 提交于 
      Avoid warnings like those:

drivers/media/pci/ddbridge/ddbridge-core.c: In function 'dvb_input_detach':
drivers/media/pci/ddbridge/ddbridge-core.c:787:6: warning: this statement may fall through [-Wimplicit-fallthrough=]
   if (input->fe) {
      ^
drivers/media/pci/ddbridge/ddbridge-core.c:792:2: note: here
  case 4:
  ^~~~
...

On several cases, it is just that gcc 7.1 is not capable of
understanding the comment, but on other places, we need an
annotation.
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      06eeefe8
  13. 28 2月, 2017 1 次提交
  15. 08 2月, 2017 1 次提交
  17. 21 10月, 2016 1 次提交
    • M
      [media] dvb-usb: don't break long lines · f319ed91
      由 Mauro Carvalho Chehab 提交于 
      Due to the 80-cols restrictions, and latter due to checkpatch
warnings, several strings were broken into multiple lines. This
is not considered a good practice anymore, as it makes harder
to grep for strings at the source code.

As we're right now fixing other drivers due to KERN_CONT, we need
to be able to identify what printk strings don't end with a "\n".
It is a way easier to detect those if we don't break long lines.

So, join those continuation lines.

The patch was generated via the script below, and manually
adjusted if needed.

</script>
use Text::Tabs;
while (<>) {
	if ($next ne "") {
		$c=$_;
		if ($c =~ /^\s+\"(.*)/) {
			$c2=$1;
			$next =~ s/\"\n$//;
			$n = expand($next);
			$funpos = index($n, '(');
			$pos = index($c2, '",');
			if ($funpos && $pos > 0) {
				$s1 = substr $c2, 0, $pos + 2;
				$s2 = ' ' x ($funpos + 1) . substr $c2, $pos + 2;
				$s2 =~ s/^\s+//;

				$s2 = ' ' x ($funpos + 1) . $s2 if ($s2 ne "");

				print unexpand("$next$s1\n");
				print unexpand("$s2\n") if ($s2 ne "");
			} else {
				print "$next$c2\n";
			}
			$next="";
			next;
		} else {
			print $next;
		}
		$next="";
	} else {
		if (m/\"$/) {
			if (!m/\\n\"$/) {
				$next=$_;
				next;
			}
		}
	}
	print $_;
}
</script>
Signed-off-by: NMauro Carvalho Chehab <mchehab@s-opensource.com>
      f319ed91
  19. 14 10月, 2016 1 次提交
  21. 10 5月, 2016 1 次提交
  23. 25 1月, 2016 1 次提交
  25. 10 6月, 2015 1 次提交
    • M
      [media] dvb: Get rid of typedev usage for enums · 0df289a2
      由 Mauro Carvalho Chehab 提交于 
      The DVB API was originally defined using typedefs. This is against
Kernel CodingStyle, and there's no good usage here. While we can't
remove its usage on userspace, we can avoid its usage in Kernelspace.

So, let's do it.

This patch was generated by this shell script:

	for j in $(grep typedef include/uapi/linux/dvb/frontend.h |cut -d' ' -f 3); do for i in $(find drivers/media -name '*.[ch]' -type f) $(find drivers/staging/media -name '*.[ch]' -type f); do sed "s,${j}_t,enum $j," <$i >a && mv a $i; done; done

While here, make CodingStyle fixes on the affected lines.
Signed-off-by: NMauro Carvalho Chehab <mchehab@osg.samsung.com>
Acked-by: Stefan Richter <stefanr@s5r6.in-berlin.de> # for drivers/media/firewire/*
      0df289a2
  27. 15 5月, 2015 1 次提交
  29. 14 5月, 2015 1 次提交
  31. 01 5月, 2015 1 次提交
  33. 08 4月, 2015 1 次提交
  35. 23 9月, 2014 1 次提交
  37. 26 7月, 2014 1 次提交
  39. 24 7月, 2014 1 次提交
    • D
      [media] rc-core: document the protocol type · 120703f9
      由 David Härdeman 提交于 
      Right now the protocol information is not preserved, rc-core gets handed a
scancode but has no idea which protocol it corresponds to.

This patch (which required reading through the source/keymap for all drivers,
not fun) makes the protocol information explicit which is important
documentation and makes it easier to e.g. support multiple protocols with one
decoder (think rc5 and rc-streamzap). The information isn't used yet so there
should be no functional changes.

[m.chehab@samsung.com: rebased, added cxusb and removed bad whitespacing]
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      120703f9
  41. 07 7月, 2014 1 次提交
  43. 17 6月, 2014 4 次提交
    • M
      [media] dib8000: export just one symbol · d44913c1
      由 Mauro Carvalho Chehab 提交于 
      Exporting multiple symbols don't work as it causes compilation
breakages, due to the way dvb_attach() works.

The bug happens when:
        CONFIG_DVB_DIB8000=m
	CONFIG_DVB_USB_DIB0700=y

As a bonus, dib8000 won't be loaded anymore if the device uses
a different frontend, reducing the memory footprint.

Tested with both Pixelview PV-D231 and MyGica S870.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      d44913c1
    • M
      [media] dib8000: rename dib8000_attach to dib8000_init · b9bc7d59
      由 Mauro Carvalho Chehab 提交于 
      Well, what we call as "foo_attach" is the method that should
be called by the dvb_attach() macro.

It should be noticed that the name "dvb_attach" is really a
bad name and don't express what it does.

dvb_attach() basically does three things, if the frontend is
compiled as a module:
- It lookups for the module that it is known to have the
  given symbol name and requests such module;
- It increments the module usage (anonymously - so lsmod
  doesn't print who loaded the module);
- after loading the module, it runs the function associated
  with the dynamic symbol.

When compiled as builtin, it just calls the function given to it.

As dvb_attach() increments refcount, it can't be (easily)
called more than once for the same module, or the kernel
will deny to remove the module, because refcount will never
be zeroed.

In other words, the function name given to dvb_attach()
should be one single symbol that will always be called
before any other function on that module to be used.

For almost all DVB frontends, there's just one function,
but, on dib8000, there are several exported symbols.

We need to get rid of all those direct calls, because they
cause compilation breakages when bridge is builtin and
frontend is module, we'll need to add a new function that
will be the first one to be called, whatever initialization
is needed.

So, let's rename this function, in order to prepare for
a next patch that will add a new attach() function that
will be the only one exported by this module.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      b9bc7d59
    • M
      [media] dib7000: export just one symbol · 8abe4a0a
      由 Mauro Carvalho Chehab 提交于 
      Exporting multiple symbols don't work as it causes compilation
breakages, due to the way dvb_attach() works.

This were reported several times, like:

   drivers/built-in.o: In function `cxusb_dualdig4_rev2_tuner_attach':
>> cxusb.c:(.text+0x27d4b5): undefined reference to `dib7000p_get_i2c_master'
   drivers/built-in.o: In function `dib7070_set_param_override':
   cxusb.c:(.text+0x27d5a5): undefined reference to `dib0070_wbd_offset'
>> cxusb.c:(.text+0x27d5be): undefined reference to `dib7000p_set_wbd_ref'
   drivers/built-in.o: In function `dib7070_tuner_reset':
>> cxusb.c:(.text+0x27d5f9): undefined reference to `dib7000p_set_gpio'
   drivers/built-in.o: In function `cxusb_dualdig4_rev2_frontend_attach':
>> cxusb.c:(.text+0x27df5c): undefined reference to `dib7000p_i2c_enumeration'

In this specific report:
	CONFIG_DVB_USB_CXUSB=y
	CONFIG_DVB_DIB7000P=m

But the same type of bug can happen if:
	CONFIG_DVB_DIB7000P=m
and one of the bridge drivers is compiled builtin (cxusb, cx23885-dvb
and/or dib0700).

As a bonus, dib7000p won't be loaded anymore if the device uses
a different frontend, reducing the memory footprint.

Tested with Hauppauge Nova-TD (2 frontends).
Reported-by: NFengguang Wu <fengguang.wu@intel.com>
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      8abe4a0a
    • M
      [media] dib7000p: rename dib7000p_attach to dib7000p_init · 7f67d96a
      由 Mauro Carvalho Chehab 提交于 
      Well, what we call as "foo_attach" is the method that should
be called by the dvb_attach() macro.

It should be noticed that the name "dvb_attach" is really a
bad name and don't express what it does.

dvb_attach() basically does three things, if the frontend is
compiled as a module:
- It lookups for the module that it is known to have the
  given symbol name and requests such module;
- It increments the module usage (anonymously - so lsmod
  doesn't print who loaded the module);
- after loading the module, it runs the function associated
  with the dynamic symbol.

When compiled as builtin, it just calls the function given to it.

As dvb_attach() increments refcount, it can't be (easily)
called more than once for the same module, or the kernel
will deny to remove the module, because refcount will never
be zeroed.

In other words, the function name given to dvb_attach()
should be one single symbol that will always be called
before any other function on that module to be used.

For almost all DVB frontends, there's just one function.

However, the dib7000p initialization can require up to 3
functions to be called:
	- dib7000p_get_i2c_master;
	- dib7000p_i2c_enumeration;
	- dib7000p_init (before this patch dib7000_attach).

(plus a bunch of other functions that the bridge driver will
need to call).

As we need to get rid of all those direct calls, because they
cause compilation breakages when bridge is builtin and
frontend is module, we'll need to add a new function that
will be the first one to be called, whatever initialization
is needed.

So, let's rename the function that probes and init the hardware
to dib7000p_init.

A latter patch will add a new dib7000p_attach that will be
used as originally conceived by dvb_attach() way.
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      7f67d96a
  45. 26 5月, 2014 1 次提交
    • M
      [media] dib0700: fix RC support on Hauppauge Nova-TD · c4018fa2
      由 Mauro Carvalho Chehab 提交于 
      The RC support o Nova-TD is broken, as the RC endpoint there
is an interrupt endpoint.

That produces an ugly calltrace at the Kernel logs:

	WARNING: CPU: 2 PID: 56 at drivers/usb/core/urb.c:450 usb_submit_urb+0x1fd/0x5c0()
	usb 1-1.2: BOGUS urb xfer, pipe 3 != type 1
	Modules linked in: rc_dib0700_rc5(OF) dvb_usb_dib0700(OF) dib9000(OF) dib8000(OF) dib7000m(OF) dib0090(OF) dib0070(OF) dib7000p(OF) dib3000mc(OF) dibx000_common(OF) dvb_usb(OF) rc_core(OF) snd_usb_audio snd_usbmidi_lib snd_hwdep snd_rawmidi snd_seq snd_seq_device snd_pcm snd_timer snd soundcore bnep bluetooth 6lowpan_iphc rfkill au0828(OF) xc5000(OF) au8522_dig(OF) au8522_common(OF) tveeprom(OF) dvb_core(OF) nouveau i915 mxm_wmi ttm i2c_algo_bit drm_kms_helper drm r8169 mii i2c_core video wmi [last unloaded: au0828]
	CPU: 2 PID: 56 Comm: khubd Tainted: GF          O 3.14.2-200.fc20.x86_64 #1
	Hardware name: SAMSUNG ELECTRONICS CO., LTD. 550P5C/550P7C/SAMSUNG_NP1234567890, BIOS P05ABI.016.130917.dg 09/17/2013
	 0000000000000000 00000000610866bc ffff880223703860 ffffffff816eec92
	 ffff8802237038a8 ffff880223703898 ffffffff8108a1bd ffff8800916a2180
	 ffff8801d5b16000 0000000000000003 0000000000000003 0000000000000020
	Call Trace:
	 [<ffffffff816eec92>] dump_stack+0x45/0x56
	 [<ffffffff8108a1bd>] warn_slowpath_common+0x7d/0xa0
	 [<ffffffff8108a23c>] warn_slowpath_fmt+0x5c/0x80
	 [<ffffffff814e3ebd>] usb_submit_urb+0x1fd/0x5c0
	 [<ffffffffa0445925>] dib0700_rc_setup+0xb5/0x120 [dvb_usb_dib0700]
	 [<ffffffffa0445a58>] dib0700_probe+0xc8/0x130 [dvb_usb_dib0700]
	...

Fix it by detecting if the endpoint is bulk or interrupt.

Tested with both Hauppauge Nova-TD model 52009 (interrupt) and with a
		 Prolink Pixelview SBTVD model PV-D231U (bulk).
Signed-off-by: NMauro Carvalho Chehab <m.chehab@samsung.com>
      c4018fa2
  47. 22 7月, 2013 1 次提交
  49. 23 4月, 2013 4 次提交
  51. 27 10月, 2012 1 次提交
    • D
      [media] rc-core: add separate defines for protocol bitmaps and numbers · c003ab1b
      由 David Härdeman 提交于 
      The RC_TYPE_* defines are currently used both where a single protocol is
expected and where a bitmap of protocols is expected.

Functions like rc_keydown() and functions which add/remove entries to the
keytable want a single protocol. Future userspace APIs would also
benefit from numeric protocols (rather than bitmap ones). Keytables are
smaller if they can use a small(ish) integer rather than a bitmap.

Other functions or struct members (e.g. allowed_protos,
enabled_protocols, etc) accept multiple protocols and need a bitmap.

Using different types reduces the risk of programmer error. Using a
protocol enum whereever possible also makes for a more future-proof
user-space API as we don't need to worry about a sufficient number of
bits being available (e.g. in structs used for ioctl() calls).

The use of both a number and a corresponding bit is dalso one in e.g.
the input subsystem as well (see all the references to set/clear bit when
changing keytables for example).

This patch separate the different usages in preparation for
upcoming patches.

Where a single protocol is expected, enum rc_type is used; where one or more
protocol(s) are expected, something like u64 is used.

The patch has been rewritten so that the format of the sysfs "protocols"
file is no longer altered (at the loss of some detail). The file itself
should probably be deprecated in the future though.
Signed-off-by: NDavid Härdeman <david@hardeman.nu>
Cc: Andy Walls <awalls@md.metrocast.net>
Cc: Maxim Levitsky <maximlevitsky@gmail.com>
Cc: Antti Palosaari <crope@iki.fi>
Cc: Mike Isely <isely@pobox.com>
Signed-off-by: NMauro Carvalho Chehab <mchehab@redhat.com>
      c003ab1b
  53. 14 8月, 2012 1 次提交
  55. 20 4月, 2012 1 次提交
  57. 18 1月, 2012 4 次提交
  59. 31 12月, 2011 2 次提交