An error occurred fetching the project authors.
  1. 06 Oct, 2017 3 commits
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Move platform_get_irq call to bcm_probe · 4a56f891
      Hans de Goede authored
      The ACPI subsys is going to move over to instantiating ACPI enumerated
      HCIs as serdevs, rather then as platform devices.
      
      Most of the code in bcm_platform_probe is actually not platform
      specific and will work with any struct device passed to it, the one
      platform specific call in bcm_platform_probe is platform_get_irq.
      
      This commit moves platform_get_irq call to the platform-driver's bcm_probe
      function, this is a preparation patch for adding (runtime)pm support to
      the serdev path.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      4a56f891
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Move bcm_platform_probe call out of bcm_acpi_probe · 201762e2
      Hans de Goede authored
      Since bcm_acpi_probe calls bcm_platform_probe, bcm_probe always ends up
      calling bcm_platform_probe.
      
      This commit simplifies things by making bcm_probe always call
      bcm_platform_probe itself.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      201762e2
    • Hans de Goede's avatar
      Bluetooth: hci_bcm: Fix setting of irq trigger type · 227630cc
      Hans de Goede authored
      This commit fixes 2 issues with host-wake irq trigger type handling
      in hci_bcm:
      
      1) bcm_setup_sleep sets sleep_params.host_wake_active based on
      bcm_device.irq_polarity, but bcm_request_irq was always requesting
      IRQF_TRIGGER_RISING as trigger type independent of irq_polarity.
      
      This was a problem when the irq is described as a GpioInt rather then
      an Interrupt in the DSDT as for GpioInt-s the value passed to request_irq
      is honored. This commit fixes this by requesting the correct trigger
      type depending on bcm_device.irq_polarity.
      
      2) bcm_device.irq_polarity was used to directly store an ACPI polarity
      value (ACPI_ACTIVE_*). This is undesirable because hci_bcm is also
      used with device-tree and checking for something like ACPI_ACTIVE_LOW
      in a non ACPI specific function like bcm_request_irq feels wrong.
      
      This commit fixes this by renaming irq_polarity to irq_active_low
      and changing its type to a bool.
      Signed-off-by: default avatarHans de Goede <hdegoede@redhat.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      227630cc
  2. 17 Aug, 2017 2 commits
    • Marcel Holtmann's avatar
      Bluetooth: hci_bcm: Handle empty packet after firmware loading · 01d5e44a
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      01d5e44a
    • Loic Poulain's avatar
      Bluetooth: hci_bcm: Add serdev support · 33cd149e
      Loic Poulain authored
      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: default avatarLoic Poulain <loic.poulain@gmail.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      33cd149e
  3. 16 Aug, 2017 1 commit
    • Marcel Holtmann's avatar
      Bluetooth: hci_bcm: Use operation speed of 4Mbps only for ACPI devices · 74183a1c
      Marcel Holtmann authored
      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: default avatarMarcel Holtmann <marcel@holtmann.org>
      Signed-off-by: default avatarJohan Hedberg <johan.hedberg@intel.com>
      74183a1c
  4. 20 Jul, 2017 1 commit
  5. 29 Jun, 2017 1 commit
  6. 27 Jun, 2017 1 commit
  7. 16 Jun, 2017 2 commits
    • Johannes Berg's avatar
      networking: add and use skb_put_u8() · 634fef61
      Johannes Berg authored
      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: default avatarJoe Perches <joe@perches.com>
      Suggested-by: default avatarBjørn Mork <bjorn@mork.no>
      Signed-off-by: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      634fef61
    • Johannes Berg's avatar
      networking: make skb_put & friends return void pointers · 4df864c1
      Johannes Berg authored
      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: default avatarJohannes Berg <johannes.berg@intel.com>
      Signed-off-by: default avatarDavid S. Miller <davem@davemloft.net>
      4df864c1
  8. 09 Jun, 2017 1 commit
  9. 12 Apr, 2017 3 commits
  10. 16 Feb, 2017 1 commit
    • Daniel Drake's avatar
      Bluetooth: hci_bcm: Add support for BCM2E95 and BCM2E96 · 89ab37b4
      Daniel Drake authored
      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: default avatarDaniel Drake <drake@endlessm.com>
      Signed-off-by: default avatarMarcel Holtmann <marcel@holtmann.org>
      89ab37b4
  11. 13 Oct, 2016 1 commit
  12. 19 Sep, 2016 1 commit
  13. 08 Apr, 2016 1 commit
  14. 10 Mar, 2016 1 commit
  15. 23 Feb, 2016 2 commits
  16. 04 Jan, 2016 2 commits
  17. 20 Dec, 2015 1 commit
  18. 19 Nov, 2015 1 commit
  19. 22 Oct, 2015 1 commit
  20. 21 Oct, 2015 1 commit
  21. 08 Oct, 2015 2 commits
  22. 01 Oct, 2015 5 commits
  23. 24 Sep, 2015 3 commits
  24. 17 Sep, 2015 2 commits