Skip to content

cloud-kernel
cloud-kernel

openanolis / cloud-kernel
1 年多 前同步成功

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 27 12月, 2017 1 次提交
    • L
      Bluetooth: hci_bcm: Streamline runtime PM code · 43fff768
      由 Lukas Wunner 提交于 
      This driver seeks to force the Bluetooth device on for the duration of
5 seconds when the Bluetooth device has woken the host and after a
complete packet has been received.  It does that by calling:

    pm_runtime_get();
    pm_runtime_mark_last_busy();
    pm_runtime_put_autosuspend();

The same can be achieved more succinctly with:

    pm_request_resume();

That's because after runtime resuming the device, rpm_resume() invokes
pm_runtime_mark_last_busy() followed by rpm_idle(), which will cause
the device to be suspended after expiration of the autosuspend_delay.

No functional change intended.

Cc: Frédéric Danis <frederic.danis.oss@gmail.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      43fff768
  3. 13 12月, 2017 1 次提交
  5. 14 10月, 2017 1 次提交
  7. 12 10月, 2017 1 次提交
  9. 10 10月, 2017 2 次提交
    • I
      Bluetooth: hci_bcm: Add support for MINIX Z83-4 based devices · 1bdb68b2
      由 Ian W MORRISON 提交于 
      The MINIX NEO Z83-4 and MINIX NEO Z83-4 Pro devices use an AP6255 chip for
wifi and bluetooth. Bluetooth requires an ACPI device id of BCM2EA4 with
BCM4345 rev C0 firmware.

This patch adds the device id and to use trigger type IRQF_TRIGGER_FALLING
as defined by 'GpioInt' in the ACPI DSDT table:

    Device (BLT0)
    {
        Name (_HID, "BCM2EA4")  // _HID: Hardware ID
        Method (_STA, 0, NotSerialized)  // _STA: Status
        {
            Return (0x0F)
        }

        Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
        {
            Name (UBUF, ResourceTemplate ()
            {
                UartSerialBusV2 (0x0001C200, DataBitsEight, StopBitsOne,
                    0xFC, LittleEndian, ParityTypeNone, FlowControlHardware,
                    0x0020, 0x0020, "\\_SB.PCI0.URT1",
                    0x00, ResourceConsumer, , Exclusive,
                    )
                GpioInt (Level, ActiveLow, Exclusive, PullNone, 0x0000,
                    "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0005
                    }
                GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0007
                    }
                GpioIo (Exclusive, PullDefault, 0x0000, 0x0000, IoRestrictionOutputOnly,
                    "\\_SB.GPO1", 0x00, ResourceConsumer, ,
                    )
                    {   // Pin list
                        0x0004
                    }
            })
            Return (UBUF) /* \_SB_.PCI0.URT1.BLT0._CRS.UBUF */
        }
    }
Signed-off-by: NIan W MORRISON <ianwmorrison@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      1bdb68b2
    • I
      Bluetooth: hci_bcm: Correct context of IRQ polarity message · e8bfe868
      由 Ian W MORRISON 提交于 
      As the overwriting of IRQ polarity to active low occurs during the driver
probe using 'bt_dev_warn' to display the warning results in '(null)' being
displayed for the device. This patch uses 'dev_warn' to correctly display
the device in the warning instead.
Signed-off-by: NIan W MORRISON <ianwmorrison@gmail.com>
Reviewed-by: NHans de Goede <hdegoede@redhat.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      e8bfe868
  11. 07 10月, 2017 8 次提交
  13. 18 8月, 2017 2 次提交
    • M
      Bluetooth: hci_bcm: Handle empty packet after firmware loading · 01d5e44a
      由 Marcel Holtmann 提交于 
      The Broadcom controller on the Raspberry Pi3 sends an empty packet with
packet type 0x00 after launching the firmware. This will cause logging
of errors.

  Bluetooth: hci0: Frame reassembly failed (-84)

Since this seems to be an intented behaviour of the controller, handle
it gracefully by parsing that empty packet with packet type 0x00 and
then just simply report it as diagnostic packet.

With that change no errors are logging and the packet itself is actually
recorded in the Bluetooth monitor traces.

  < HCI Command: Broadcom Launch RAM (0x3f|0x004e) plen 4
         Address: 0xffffffff
  > HCI Event: Command Complete (0x0e) plen 4
       Broadcom Launch RAM (0x3f|0x004e) ncmd 1
         Status: Success (0x00)
  = Vendor Diagnostic (len 0)
  < HCI Command: Broadcom Update UART Baud Rate (0x3f|0x0018) plen 6
         00 00 00 10 0e 00                                ......
  > HCI Event: Command Complete (0x0e) plen 4
       Broadcom Update UART Baud Rate (0x3f|0x0018) ncmd 1
         Status: Success (0x00)
  < HCI Command: Reset (0x03|0x0003) plen 0
  > HCI Event: Command Complete (0x0e) plen 4
       Reset (0x03|0x0003) ncmd 1
         Status: Success (0x00)
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      01d5e44a
    • L
      Bluetooth: hci_bcm: Add serdev support · 33cd149e
      由 Loic Poulain 提交于 
      Add basic support for Broadcom serial slave devices.
Probe the serial device, retrieve its maximum speed and
register a new hci uart device.

Tested/compatible with bcm43438 (RPi3).
Signed-off-by: NLoic Poulain <loic.poulain@gmail.com>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      33cd149e
  15. 16 8月, 2017 1 次提交
    • M
      Bluetooth: hci_bcm: Use operation speed of 4Mbps only for ACPI devices · 74183a1c
      由 Marcel Holtmann 提交于 
      Not all Broadcom controller support the 4Mbps operational speed on UART
devices. This is because the UART clock setting changes might not be
supported.

  < HCI Command: Broadcom Write UART Clock Setting (0x3f|0x0045) plen 1
         01                                               .
  > HCI Event: Command Complete (0x0e) plen 4
       Broadcom Write UART Clock Setting (0x3f|0x0045) ncmd 1
         Status: Unknown HCI Command (0x01)

To support any operational speed higher than 3Mbps, support for this
command is required. With that respect it is better to not enforce any
operational speed by default. Only when its support is known, then allow
for higher operational speed.

This patch assigns the 4Mbps opertional speed only for devices
discovered through ACPI and leave all others at the default 115200.
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
Signed-off-by: NJohan Hedberg <johan.hedberg@intel.com>
      74183a1c
  17. 20 7月, 2017 1 次提交
  19. 29 6月, 2017 1 次提交
  21. 28 6月, 2017 1 次提交
  23. 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
  25. 10 6月, 2017 1 次提交
  27. 13 4月, 2017 3 次提交
  29. 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
  31. 13 10月, 2016 1 次提交
  33. 20 9月, 2016 1 次提交
  35. 09 4月, 2016 1 次提交
  37. 11 3月, 2016 1 次提交
  39. 24 2月, 2016 2 次提交
  41. 05 1月, 2016 2 次提交
  43. 20 12月, 2015 1 次提交
  45. 20 11月, 2015 1 次提交
  47. 22 10月, 2015 1 次提交
  49. 21 10月, 2015 1 次提交
  51. 08 10月, 2015 1 次提交