Skip to content

cloud-kernel
cloud-kernel

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

通知 170
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 1月, 2018 1 次提交
    • L
      Bluetooth: hci_bcm: Mandate presence of shutdown and device wake GPIO · 3e81a4ca
      由 Lukas Wunner 提交于 
      Commit 0395ffc1 ("Bluetooth: hci_bcm: Add PM for BCM devices")
amended this driver to request a shutdown and device wake GPIO on probe,
but mandated that only one of them need to be present:

	/* Make sure at-least one of the GPIO is defined and that
	 * a name is specified for this instance
	 */
	if ((!dev->device_wakeup && !dev->shutdown) || !dev->name) {
		dev_err(&pdev->dev, "invalid platform data\n");
		return -EINVAL;
	}

However the same commit added a call to bcm_gpio_set_power() to the
->probe hook, which unconditionally accesses *both* GPIOs.  Luckily,
the resulting NULL pointer deref was never reported, suggesting there's
no machine where either GPIO is missing.

Commit 8a920568 ("Bluetooth: hci_bcm: Add (runtime)pm support to the
serdev driver") removed the check whether at least one of the GPIOs is
present without specifying a reason.

Because commit 62aaefa7 ("Bluetooth: hci_bcm: improve use of gpios
API") refactored the driver to use devm_gpiod_get_optional() instead of
devm_gpiod_get(), one is now tempted to believe that the driver doesn't
require *any* of the two GPIOs.

Which is wrong, the driver still requires both GPIOs to avoid a NULL
pointer deref.  To this end, establish the status quo ante and request
the GPIOs with devm_gpiod_get() again.  Bail out of ->probe if either
of them is missing.

Oddly enough, whereas bcm_gpio_set_power() accesses the device wake pin
unconditionally, bcm_suspend_device() and bcm_resume_device() do check
for its presence before accessing it.  Those checks are superfluous,
so remove them.

Cc: Frédéric Danis <frederic.danis.oss@gmail.com>
Cc: Loic Poulain <loic.poulain@linaro.org>
Cc: Hans de Goede <hdegoede@redhat.com>
Cc: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Cc: Linus Walleij <linus.walleij@linaro.org>
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      3e81a4ca
  3. 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
  5. 13 12月, 2017 1 次提交
  7. 14 10月, 2017 1 次提交
  9. 12 10月, 2017 1 次提交
  11. 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
  13. 07 10月, 2017 8 次提交
  15. 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
  17. 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
  19. 20 7月, 2017 1 次提交
  21. 29 6月, 2017 1 次提交
  23. 28 6月, 2017 1 次提交
  25. 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
  27. 10 6月, 2017 1 次提交
  29. 13 4月, 2017 3 次提交
  31. 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
  33. 13 10月, 2016 1 次提交
  35. 20 9月, 2016 1 次提交
  37. 09 4月, 2016 1 次提交
  39. 11 3月, 2016 1 次提交
  41. 24 2月, 2016 2 次提交
  43. 05 1月, 2016 2 次提交
  45. 20 12月, 2015 1 次提交
  47. 20 11月, 2015 1 次提交
  49. 22 10月, 2015 1 次提交
  51. 21 10月, 2015 1 次提交