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: Daniel Drake <drake@endlessm.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
ACPI table for BCM2E55 of Lenovo ThinkPad 8 is not correct.
Set correctly IRQ polarity for this device, fixing the issue of bluetooth
never resuming after autosuspend PM.
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Lenovo ThinkPad Tablet 8 with BCM43241 rev B5 chipset uses the BCM2E55
ACPI ID for Bluetooth. Add it to the list of supported devices.
Signed-off-by: Jérôme de Bretagne <jerome.debretagne@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Recent macbooks (early 2015) with BCM43241 use this ACPI ID. Add it to the
list of supported devices.
Reported-by: Leif Liddy <leif.liddy@gmail.com>
Signed-off-by: Mika Westerberg <mika.westerberg@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
This ACPI ID is used at least by HP for their Omni 10 5600eg tablet.
Signed-off-by: J.J. Meijer <jjmeijer88@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
These are used at least by Acer with BCM43241.
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The IDs should all be for Broadcom BCM43241 module, and
hci_bcm is now the proper driver for them. This removes one
of two different ways of handling PM with the module.
Cc: Johannes Berg <johannes@sipsolutions.net>
Signed-off-by: Heikki Krogerus <heikki.krogerus@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Add BCM2E65 device in acpi_device_id table used on Asus T100TAF.
Signed-off-by: Luka Karinja <luka.karinja@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The new hci_skb_pkt_* wrappers are mainly intented for drivers to
require less knowledge about bt_cb(sbk) handling. So after converting
the core packet handling, convert all drivers.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
bt_skb_alloc() returns NULL on error, it never returns an ERR_PTR.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Provide an early indication about the manufacturer information so that
it can be forwarded into monitor channel.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The set_diag driver callback allows enabling and disabling the vendor
specific diagnostic information. Since Broadcom chips have support for
a dedicated LM_DIAG channel, hook it up accordingly.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The Broadcom UART based controllers can send LM_DIAG messages with the
identifier 0x07 inside the HCI stream. These messages are 63 octets in
size and have no variable payload or length indicator.
This patch adds correct parsing information for the h4_recv_buf handler
and in case these packets are received, they are forwarded to the
Bluetooth core via hci_recv_diag interface.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This device has always ACPI companion because driver supports only ACPI
enumeration. Therefore there is no need to test it in bcm_acpi_probe() and
we can pass it directly to acpi_dev_get_resources() (which will return
-EINVAL in case of NULL argument is passed).
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Tree wide grep for "hci_bcm" doesn't reveal there is any code registering
this platform device and "struct acpi_device_id" use for passing the
platform data looks a debug/test code leftover to me.
I'm assuming this driver effectively supports only ACPI enumeration and
thus test for ACPI_HANDLE() and platform data can be removed.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
There is no need to call acpi_match_device() in driver's probe path and
verify does it find a match to given ACPI _HIDs in .acpi_match_table as
driver/platform/acpi core code has found the match prior calling the probe.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Driver doesn't handle possible error from acpi_dev_get_resources(). Test it
and return the error code in case of error.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Caller of acpi_dev_get_resources() should free the constructed resource
list by calling the acpi_dev_free_resource_list() in order to avoid memory
leak.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Adds autosuspend runtime functionality to BCM UART driver.
Autosuspend is enabled at end of bcm_setup.
bcm_device_lock is used for system sleep functions as they can be
called at any time.
bcm_device_lock is not held for runtime suspend functions as this
is only enabled as long as platform device is opened.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Change some CONFIG_PM_SLEEP to CONFIG_PM as hu and is_suspended parameters
will be used during PM runtime callbacks.
Add bcm_suspend_device() and bcm_resume_device() which performs link
management for PM callbacks.
These functions will be used for runtime management.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
ACPI table for BCM2E39 of T100TA is not correct.
Set correct irq_polarity for this device.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Retrieve the Interruption used by BCM device, which can be declared
as Interruption or GpioInt in the ACPI table.
Retrieve IRQ polarity from the ACPI table to use it for host_wake_active
parameter of Setup Sleep vendor specific command.
Configure BCM device to wake-up the host.
Enable IRQ wake while suspended.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Replace spinlock by mutex to be able to use bcm_device_lock in
sleepable context like devm_request_threaded_irq or upcomming PM support.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If bcm_suspend is called whithout device opened there is a crash as
it tries to use bdev->hu which is NULL.
Rename bcm_device_list_lock to bcm_device_lock as it does not only apply
to bcm_device_list.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
We should not sleep while holding a spinlock.
bcm_gpio_set_power is called while holding the bcm_device_list lock.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
The kbuild test robot reported implicit declaration of function
'acpi_dev_get_resources'.
Surround ACPI function by CONFIG_ACPI test.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
devm_gpiod_get currently has an optional parameter to set initial
direction and value for the requested gpio. Make use of this to simplify
the driver and make it not fail to build when this parameter is made
mandatory (which is scheduled for 4.3-rc1).
Moreover use the _optional variant of devm_gpiod_get to simplify error
handling (which also gets more strict for free).
Signed-off-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Parse platform_device's ACPI to retrieve UART init speed.
When BCM device is open, check if its TTY has same parent as one of the
platform devices saved. If yes, use platform_device's init speed.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Retrieve "shutdown" and "device_wakeup" GPIOs from ACPI.
Set device off during platform device enumeration.
Set device on only when attached.
As driver can be unbound we need to check if the bcm_device still exists
before calling GPIO's functions, this is protected using device_list_lock.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
hu->proto->*speed will always be used for all device where it is set.
But hu->*speed should be used if exist, so the test should be swapped.
The equivalent change is needed in bcm_setup() of hci_bcm.c.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
If h4_recv_buf() return ERR_PTR instead sk_buff pointer, it should be
cleared once PTR_ERR is completed for the further dereference such as
h4_recv(), or h4_close().
Signed-off-by: Chan-yeol Park <chanyeol.park@samsung.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Use btbcm helpers to perform controller setup.
Perform host UART reset to init speed between btbcm_patchram() and
btbcm_finalize(). This may be need because firmware loading may have
reseted controller UART to init speed.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Move request/release_firmware() out of btbcm_patchram().
This allows a better error management, if request_firmware() returns an
error then the controller will be used without firmware loading and 0 is
returned.
This will imply to change btbcm_patchram() to accept a firmware instead
of firmware name.
Signed-off-by: Frederic Danis <frederic.danis@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Future H:4 based UART drivers require custom packet types and custom
receive functions. To support this, extended the h4_recv_buf function
with a packet definition table.
For the default H:4 packets types of ACL data, SCO data and events,
provide helpers to reduce the amount of code duplication.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
This adds the protocol support for Broadcom based UART devices to
enable firmware and patchram download procedure. It is a pretty
straight forward H:4 driver with the exception of actually having
its own setup and address configuration callbacks.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The new Broadcom Bluetooth support module provides generic functionality
for changing and checking the Bluetooth device address. Use these new
features instead of keeping a duplicate in the driver.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
When using vendor detection, this adds support for the Broadcom
specific address configuration command.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Daniel Drake