Skip to content

cloud-kernel
cloud-kernel

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

通知 161
Star 36
Fork 7
cloud-kernel
cloud-kernel
切换分支/标签
  1. 11 1月, 2018 5 次提交
    • L
      Bluetooth: hci_bcm: Fix unbalanced pm_runtime_disable() · f4cf6b7e
      由 Lukas Wunner 提交于 
      On ->setup, pm_runtime_enable() is only called if a valid IRQ was found,
but on ->close(), pm_runtime_disable() is called unconditionally.
Disablement of runtime PM is recorded in a counter, so every
pm_runtime_disable() needs to be balanced.  Fix it.

Cc: Frédéric Danis <frederic.danis.oss@gmail.com>
Reported-and-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>
      f4cf6b7e
    • L
      Bluetooth: hci_bcm: Fix race on close · 54ba69f9
      由 Lukas Wunner 提交于 
      Upon ->close, the driver powers the Bluetooth controller down, deasserts
the device wake pin, updates the runtime PM status to "suspended" and
finally frees the IRQ.

Because the IRQ is freed last, a runtime resume can take place after
the controller was powered down.  The impact is not grave, the worst
thing that can happen is that the device wake pin is reasserted (should
have no effect while the regulator is off) and that setting the runtime
PM status to "suspended" does not reflect reality.

Still, it's wrong, so free the IRQ first.

Cc: Frédéric Danis <frederic.danis.oss@gmail.com>
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>
      54ba69f9
    • L
      Bluetooth: hci_bcm: Clean up unnecessary #ifdef · 6d83f1ee
      由 Lukas Wunner 提交于 
      pm_runtime_disable() and pm_runtime_set_suspended() are replaced with
empty inlines if CONFIG_PM is disabled, so there's no need to #ifdef
them.

device_init_wakeup() is likewise replaced with an inline, though it's
not empty, but it and devm_free_irq() can be made conditional on
IS_ENABLED(CONFIG_PM), which is preferable to #ifdef as per section 20
of Documentation/process/coding-style.rst.

Cc: Frédéric Danis <frederic.danis.oss@gmail.com>
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>
      6d83f1ee
    • R
      Bluetooth: hci_bcm: Validate IRQ before using it · 4a59f1fa
      由 Ronald Tschalär 提交于 
      The ->close, ->suspend and ->resume hooks assume presence of a valid IRQ
if the device is wakeup capable.  However it's entirely possible that
wakeup was enabled by some other entity besides this driver and in this
case the user will get a WARN splat if no valid IRQ was found.  Avoid by
checking if the IRQ is valid, i.e. > 0.

Case in point:  On recent MacBook Pros, the Bluetooth device lacks an
IRQ (because host wakeup is handled by the SMC, independently of the
operating system), but it does possess a _PRW method (which specifies
the SMC's GPE as wake event).  The ACPI core therefore automatically
marks the physical Bluetooth device wakeup capable upon binding it to
its ACPI companion:

device_set_wakeup_capable+0x96/0xb0
acpi_bind_one+0x28a/0x310
acpi_platform_notify+0x20/0xa0
device_add+0x215/0x690
serdev_device_add+0x57/0xf0
acpi_serdev_add_device+0xc9/0x110
acpi_ns_walk_namespace+0x131/0x280
acpi_walk_namespace+0xf5/0x13d
serdev_controller_add+0x6f/0x110
serdev_tty_port_register+0x98/0xf0
tty_port_register_device_attr_serdev+0x3a/0x70
uart_add_one_port+0x268/0x500
serial8250_register_8250_port+0x32e/0x490
dw8250_probe+0x46c/0x720
platform_drv_probe+0x35/0x90
driver_probe_device+0x300/0x450
bus_for_each_drv+0x67/0xb0
__device_attach+0xde/0x160
bus_probe_device+0x9c/0xb0
device_add+0x448/0x690
platform_device_add+0x10e/0x260
mfd_add_device+0x392/0x4c0
mfd_add_devices+0xb1/0x110
intel_lpss_probe+0x2a9/0x610 [intel_lpss]
intel_lpss_pci_probe+0x7a/0xa8 [intel_lpss_pci]
Reviewed-by: NAndy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: NRonald Tschalär <ronald@innovation.ch>
[lukas: fix up ->suspend and ->resume as well, add commit message]
Signed-off-by: NLukas Wunner <lukas@wunner.de>
Signed-off-by: NMarcel Holtmann <marcel@holtmann.org>
      4a59f1fa
    • 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 次提交