Skip to content

cloud-kernel
cloud-kernel

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

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 29 6月, 2017 1 次提交
  3. 28 6月, 2017 1 次提交
  5. 16 6月, 2017 2 次提交
    • J
      networking: add and use skb_put_u8() · 634fef61
      由 Johannes Berg 提交于 
      Joe and Bjørn suggested that it'd be nicer to not have the
cast in the fairly common case of doing
	*(u8 *)skb_put(skb, 1) = c;

Add skb_put_u8() for this case, and use it across the code,
using the following spatch:

    @@
    expression SKB, C, S;
    typedef u8;
    identifier fn = {skb_put};
    fresh identifier fn2 = fn ## "_u8";
    @@
    - *(u8 *)fn(SKB, S) = C;
    + fn2(SKB, C);

Note that due to the "S", the spatch isn't perfect, it should
have checked that S is 1, but there's also places that use a
sizeof expression like sizeof(var) or sizeof(u8) etc. Turns
out that nobody ever did something like
	*(u8 *)skb_put(skb, 2) = c;

which would be wrong anyway since the second byte wouldn't be
initialized.
Suggested-by: NJoe Perches <joe@perches.com>
Suggested-by: NBjørn Mork <bjorn@mork.no>
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      634fef61
    • J
      networking: make skb_put & friends return void pointers · 4df864c1
      由 Johannes Berg 提交于 
      It seems like a historic accident that these return unsigned char *,
and in many places that means casts are required, more often than not.

Make these functions (skb_put, __skb_put and pskb_put) return void *
and remove all the casts across the tree, adding a (u8 *) cast only
where the unsigned char pointer was used directly, all done with the
following spatch:

    @@
    expression SKB, LEN;
    typedef u8;
    identifier fn = { skb_put, __skb_put };
    @@
    - *(fn(SKB, LEN))
    + *(u8 *)fn(SKB, LEN)

    @@
    expression E, SKB, LEN;
    identifier fn = { skb_put, __skb_put };
    type T;
    @@
    - E = ((T *)(fn(SKB, LEN)))
    + E = fn(SKB, LEN)

which actually doesn't cover pskb_put since there are only three
users overall.

A handful of stragglers were converted manually, notably a macro in
drivers/isdn/i4l/isdn_bsdcomp.c and, oddly enough, one of the many
instances in net/bluetooth/hci_sock.c. In the former file, I also
had to fix one whitespace problem spatch introduced.
Signed-off-by: NJohannes Berg <johannes.berg@intel.com>
Signed-off-by: NDavid S. Miller <davem@davemloft.net>
      4df864c1
  7. 10 6月, 2017 1 次提交
  9. 13 4月, 2017 3 次提交
  11. 17 2月, 2017 1 次提交
    • D
      Bluetooth: hci_bcm: Add support for BCM2E95 and BCM2E96 · 89ab37b4
      由 Daniel Drake 提交于 
      The BCM2E96 ID is used by the ECS EF20 laptop, and BCM2E95 is present
in the Weibu F3C. Both are now logged as:

     hci0: BCM: chip id 82
     hci0: BCM43341B0 (002.001.014) build 0000
     hci0: BCM (002.001.014) build 0158

The ECS vendor kernel predates the host-wakeup support in hci_bcm but
it explicitly has a comment saying that the GPIO assignment needs to be
reordered for BCM2E96:
 1. (not used in vendor driver)
 2. Device wakeup
 3. Shutdown

For both devices in question, the DSDT has these GPIOs listed in order
of GpioInt, GpioIo, GpioIo. And if we use the first one listed (GpioInt)
as the host wakeup, that interrupt handler fires while doing bluetooth
I/O.

I am assuming the convention of GPIO ordering has been changed for these
new device IDs, so lets use the new ordering on such devices.
Signed-off-by: NDaniel Drake <drake@endlessm.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      89ab37b4
  13. 13 10月, 2016 1 次提交
  15. 20 9月, 2016 1 次提交
  17. 09 4月, 2016 1 次提交
  19. 11 3月, 2016 1 次提交
  21. 24 2月, 2016 2 次提交
  23. 05 1月, 2016 2 次提交
  25. 20 12月, 2015 1 次提交
  27. 20 11月, 2015 1 次提交
  29. 22 10月, 2015 1 次提交
  31. 21 10月, 2015 1 次提交
  33. 08 10月, 2015 2 次提交
  35. 01 10月, 2015 5 次提交
  37. 24 9月, 2015 3 次提交
  39. 17 9月, 2015 3 次提交
  41. 29 8月, 2015 1 次提交
  43. 18 8月, 2015 1 次提交
  45. 12 8月, 2015 4 次提交