The Bluetooth public device address might change during controller setup
and it makes it a lot simpler for monitoring tools if they just get told
what the new address is. In addition include the manufacturer / company
information of the controller. That allows for easy vendor specific HCI
command and event handling.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

The Broadcom Bluetooth controllers have the chip name included in the
ROM firmware or later in the patchram firmware. For debugging purposes
read the local name and print it out. This is only done during setup
stage and only once before loading the firmware and once after loading
the firmware.

For the Broadcom based controllers from Apple, the name is only read once
after determining the chip id.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

When the core starts or shuts down the actual HCI transport, send a new
monitor event that indicates that this is happening. These new events
correspond to HCI_DEV_OPEN and HCI_DEV_CLOSE events.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

Setting and clearing of HCI_RUNNING flag in each and every driver is
just duplicating the same code all over the place. So instead of having
the driver do it in their hdev->open and hdev->close callbacks, set it
globally in the core transport handling.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

In all callbacks for hdev->send the status of HCI_RUNNING is checked. So
instead of repeating that code in every driver, move the check into the
hci_send_frame function before calling hdev->send.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

When opening the HCI transport via hdev->open send HCI_DEV_OPEN event
and when closing the HCI transport via hdev->close send HCI_DEV_CLOSE.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

The stack internal events that are exposed to userspace should be
limited to HCI_DEV_REG, HCI_DEV_UNREG, HCI_DEV_UP and HCI_DEV_DOWN.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

The commit 7bee8b08 allows the Read Verbose Config Info to fail
gracefully and not cause the controller setup to abort. It seems the
reason that command failed in the first place was the missing HCI Reset
to bring the controller in full Bluetooth mode.

Apple Bluetooth controllers start out in HID mode and when in that mode
the Read Verbose Config Info command is not allowed. Sending HCI Reset
switches the controller into full HCI mode.
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>

Add regmap ibt to support Intel Bluetooth silicon register access
over HCI. Intel BT/FM combo chip allows to read/write some registers
(e.g. FM registers) via its HCI interface.

Read/Write operations are performed via a HCI transaction composed of
a HCI command (host->controller) followed by a HCI command complete
event (controller->host). Read/Write Command opcodes can be specified
to the regmap init function.
We define data formats which are intel/vendor specific.

Register Read/Write HCI command payload (Host):
Field: | REG ADDR | MODE | DATA_LEN | DATA... |
size:  |   32b    |  8b  |    8b    |  8b*    |

Register Read HCI command complete event payload (Controller):
Field: | CMD STATUS | REG ADDR | DATA... |
size:  |     8b     |   32b    |  8b*    |

Register Write HCI command complete event payload (Controller):
Field: | CMD_STATUS |
size:  |     8b     |

Since this payload is HCI encapsulated, Little Endian byte order is
used.

Write/Read Example:

If we write 0x0000002a at address 0x00008c04, with opcode_write 0xfc5d,
The resulting transaction is (btmon trace):

< HCI Command (0x3f|0x005d) plen 10 [hci0]
        04 8c 00 00 02 04 2a 00 00 00
> HCI Event (0x0e) plen 4
      Unknown (0x3f|0x005d) ncmd 1
        00

Then, if we read the same register with opcode_read 0xfc5e:

< HCI Command (0x3f|0x005e) plen 6 [hci0]
        04 8c 00 00 02 04
> HCI Event (0x0e) plen 12 [hci0]
      Unknown (0x3f|0x005e) ncmd 1
        00 04 8c 00 00 2a 00 00 00
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

There was a missing return here so it meant that often
ieee802154_llsec_parse_key_id() was not called.

Fixes: a26c5fd7 ('nl802154: add support for security layer')
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Acked-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This reverts commit 9abc378c66e3d6f437eed77c1c534cbc183523f7
("ieee802154: 6lowpan: change datagram var types").

The reason is that I forgot the IPv6 fragmentation here. Our MTU of
lowpan interface is 1280 and skb->len should not above of that. If we
reach a payload above 1280 in IPv6 header then we have a IPv6
fragmentation above 802.15.4 6LoWPAN fragmentation. The type "u16" was
fine, instead I added now a WARN_ON_ONCE if skb->len is above MTU which
should never happen otherwise IPv6 on minimum MTU size is broken.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

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>

There is some unneeded code in "hci_intel" probing. First
acpi_match_device() call is needless as driver/platform/acpi core code has
already done the matching before calling the probe and the driver does not
use the returned pointer to matching _HID other than checking is it NULL.

Then tree wide grep for "hci_intel" doesn't reveal that there is any code
registering this platform device so it looks this device is always backed
with ACPI companion so also ACPI_HANDLE() test can be removed.
Signed-off-by: Jarkko Nikula <jarkko.nikula@linux.intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch fixes checkpatch warnings:
- Comparison to NULL could be re-written
- no space required after a cast
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Use <linux/io.h> instead of <asm/io.h>, fixes checkpatch
Warning;
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch adds support for increment transmit and receive stats. The
meaning of these stats are IPv6 based, which shows the stats after
running the 6lowpan adaptation layer (uncompression/compression,
fragmentation handling) on receive and before the adaptation layer
when transmit.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch fixes the data frame sequence numer (dsn) while 6lowpan
fragmentation for frag1. Currently we create one 802.15.4 header at
first, then check if it's match into one frame and at the end construct
many fragments and calling wpan_dev_hard_header for each of them,
inclusive for the first fragment. This will make the first generated
header to garbage, instead we copying this header for frag1 instead of
generate a new one which skips one dsn.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch changes datagram size variable from u16 type to unsigned int.
The reason is that an IPv6 header has an MAX_UIN16 payload length, but
the datagram size is payload + IPv6 header length. This avoids overflows
at some places.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch change the length check to len instead of mac_len for
checking if the frame control field is available to dereference.
We need to change it because I saw issues with af_packet raw sockets
and the mrf24j40 which calls this functionality. The raw socket
functionality doesn't set the mac_len but resets the skb_mac_header to
skb->data which is still correct. The issue occur at mrf24j40 only,
because the driver need to evaluate the fc fields.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch changes the mtu size of 802.15.4 interfaces. The current
setting is the meaning of the maximum transport unit with mac header,
which is 127 bytes according 802.15.4. The linux meaning of the mtu size
field is the maximum payload of a mac frame. Like in ethernet, which is
1500 bytes.

We have dynamic length of mac frames in 802.15.4, this is why we assume
the minimum header length which is hard_header_len. This contains fc and
sequence fields. These can evaluated by driver layer without additional
checks. We currently don't support to set the FCS from userspace, so we
need to subtract this from mtu size as well.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

While doing a little test with the llsec implementation I saw these
issues. We should move decryption and encruption somewhere else,
otherwise while capturing with wireshark the mac header shows secuirty
fields but the payload is plaintext.

A complete other issue is what doing with HardMAC drivers where the
payload is always plaintext. I think we need a special handling then in
userspace. We currently doesn't support any HardMAC transceivers, so we
should fix the first issue for SoftMAC transceivers.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch adds support for accessing mac802154 llsec implementation
over nl802154. I added for a new Kconfig entry to provide this
functionality CONFIG_IEEE802154_NL802154_EXPERIMENTAL. This interface is
still in development. It provides to change security parameters and
add/del/dump entries of security tables. Later we can add also a get to
get an entry by unique identifier.

Cc: Phoebe Buckheister <phoebe.buckheister@itwm.fraunhofer.de>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch uses the nla_get_le64 function instead of doing a force
converting to le64.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch adds missing inline wrappers for nla_get_le32 and
nla_get_le64. The 802.15.4 MAC byteorder is little endian and we keep
the byteorder for fields like address configuration in the same
byteorder as it comes from the MAC layer.

To provide these fields for nl802154 userspace applications, we need
these inline wrappers for netlink.

Cc: David S. Miller <davem@davemloft.net>
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

Send a HCI command and wait for command complete event.
This function serializes the requests by grabbing the req_lock.
Signed-off-by: Loic Poulain <loic.poulain@intel.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

'retransmit' being set in HCI_IBS_TX_WAKING case, using bool would be
efficient. Initialize local bool to false.
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

NOT NULL comparison modified to be readable, reported
by checkpatch.
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

NOT NULL comparison modified to be readable, reported
by checkpatch.
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

NOT NULL comparison modified to be readable, reported
by checkpatch.
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

replaced 'not null' comparison that is readable, reported by checkpatch.
Signed-off-by: Prasanna Karthik <mkarthi3@visteon.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

The callback "create" and "parse" from header_ops are called from
netdev core upper-layer functionality, like af_packet. These callbacks
assumes big endian for addresses and we should not introduce a special
byteordering handling for ieee802154 over af_packet in userspace.

We have an identical issue with setting the mac address which also
assumes big endian byteordering.
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch removes some unnecessary includes from ieee802154 header,
which was introduced by commit b609fb54adfa ("ieee802154: add helpers for
frame control checks").
Signed-off-by: Alexander Aring <alex.aring@gmail.com>
Signed-off-by: Marcel Holtmann <marcel@holtmann.org>

This patch removes a trailing semicolon which was introduced by commit
d3f1bc3 ("mrf24j40: add cca mode support") and reported by kbuild test
robot.
Signed-off-by: Alexander Aring <alex.aring@gmail.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>

rx_lock spinlock is only used in hci_uart_tty_receive() which is the
receive_buf ldisc callback.

hci_uart_tty_receive() is protected from re-entrance by its only
caller (flush_to_ldisc() in drivers/tty/tty_buffer.c) which held a
mutex (buf->lock) for this section.
This lock allows "safe use of the line discipline's receive_buf()
method by excluding the buffer work and any pending flush from using
the flip buffer." (comments from tty_buffer_lock_exclusive() in
drivers/tty/tty_buffer.c)

So, no need to double protect this resource with rx_lock.
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>