When we notify the controller of our ACL MTU we should subtract from
the buffer size not just the ACL header but also the headroom reserved
by the driver.
Change-Id: Id05b1becab3682425f9b591217ac29659a13a6d0
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add debug logs to the rx/tx fibers so issues relating to them can be
more easily debugged.
Change-Id: Ie02d3e760772a3e47ff495c47d83b23744202941
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add debug logs to the HCI core data handling to catch potential
issues.
Change-Id: I39bd3aeec9ed7b64156a9e2e899a153c0d484f38
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Including the context ID in debug logs can help track down various
issues, e.g. stack corruption.
Change-Id: I3cd70edd5bfd1d726f6d35e7331afb313cf3cacb
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The printf API has a much richer support for various format
specifiers. Switch the Bluetooth logging macros to use printf instead
of printk and make sure STDOUT_CONSOLE gets selected when
BLUETOOTH_DEBUG is selected (so printf actually works).
Change-Id: I9a9818d51a677c6c79a35fef6daca7979f61c78d
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The debug logs may cause a considerable overhead to stack utilization
(especially with printf). Increasing the fiber stack sizes when debug
is enabled decreases the chance of stack overflow.
Change-Id: I26e96c6516e0c1210e787cc5491fd5d59cbc75db
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Fix stack initialization.
When LE read buffer size returns 0 length LE buffers and controller
supports LE & BR/EDR functionality then ask controller about max ACL data
length it can accepts using BR/EDR read buffer size.
It should return value that can initialize LE MTU if that one still has 0.
Change-Id: Ib0bce89d47de5549d629a4ce771325e640443378
Signed-off-by: Arkadiusz Lichwa <arkadiusz.lichwa@tieto.com>
Build peripheral app for targets: pentium4 and ti_lm3s6965
Change-Id: Id98c94217ad39e1716b8f8bc6031b8814bae06f3
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
Update the includes in the sample apps to match what their actual
dependencies are.
Change-Id: I6fdfa4ba0cda563433d51f0ec35fef8f2ee0fa40
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add tracking of the confirmation values, remote random value and the
temporary key value. This also involves implementing the SMP e()
function with the help of the HCI_LE_Encrypt command.
Change-Id: I4cdad917e9689bbe16cd908941d0335c1c33f870
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
These values are needed later in the SMP pairing procedure as inputs
to various crypto functions.
Change-Id: I68334ed6d32625c4e7e0668300844af09018e126
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Add missing braces to a couple of one-line branches.
Change-Id: Ie4d703eede3cc03b823bd0a0764a5b999f317322
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
The SMP procedures require us to establish a local random number. Use
the HCI_LE_Rand command to generate the necessary 16 bytes (the
command needs to be called twice since it only returns 8 bytes at a
time). Store this number in the SMP context.
To help debugging with various crypto related values add a local h()
helper function for printk/BT_DBG to do hexadecimal conversion.
Change-Id: Id3e8793a77ac635023b3cc3a94e8679170455870
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
We'll need to know the remote address for connections e.g. when
performing SMP based pairing.
Change-Id: I7e398a75c2418ec534b3cac15ab72f76586c2e9b
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
All fixed channels will need per-connection contexts. Right now in
addition to the L2CAP (LE) signaling channel the other two fixed ones
are ATT and SMP.
Change-Id: I56dda6b903ef703e453438e03a99c704aa77899a
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
In preparation for having per-fixed channel contexts move the L2CAP
signaling channel specific data into a dedicated struct.
Change-Id: Iaacb5e1c7408be67740434f31ef56f94706ad327
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
For LE-only controller init procedure should wait for last HCI command
(Set Controller To Host Flow Control) to complete before returning.
Change-Id: Ic01e0cbaebf19d61560faab2ae01205c2eb22b77
Signed-off-by: Szymon Janc <szymon.janc@tieto.com>
The code would only have worked for reports with num_reports being
equal to 1. Any event with multiple reports would have been
incorrectly parsed because of a missing bt_buf_pull() for the initial
one-byte num_reports value.
Change-Id: I0ac92edb792d559fb8ff84e40a4b4766f46afe58
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
To make the bt_buf APIs consistent with the recent bt_but_add changes
and more user friendly, change the pull() and push() return values
also to 'void *'.
Change-Id: I25242635c87882db99152735c22316d4de00d363
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Now that bt_buf_add() returns 'void *' there's no need to explicitly
type cast its return value anymore.
Change-Id: I6d5c9d323dc08cb5a2b928977c1bbf3d741e5d8e
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Almost all callers of bt_buf_add end up having to do explicit type
casts of the return value since 'uint8_t *' rarely fits what's needed.
Changing the return type to 'void *' removes this extra type casting
need and makes the API friendlier to its users.
Change-Id: I6a79605006153b6d09f0d662a051cb599af68c37
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
Remove the memcpy code and instead use bt_buf_pull_le16 for unaligned
access and byte order conversion.
Change-Id: I0216042566e27d6a513b302ae1ea78b49f2f1c31
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
bt_buf_pull_le16 convert the initial 16 bits to little endian.
Change-Id: I6f6e9d63fc19b0579d9f445e15e975929fc63ba9
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
Both Write Command and Signed Write command should use their respective
packed struct.
Change-Id: Id786d1e0ee0327f662c68fa1d2f3d3bf19a237fc
Signed-off-by: Luiz Augusto von Dentz <luiz.von.dentz@intel.com>
IRQ and registers are hardware and driver specific information and as
such should no be exposed through the generic API.
Change-Id: I33e6d7ec7bd9fb82a4e343d99b7a5c17886d1470
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Now that UART drivers are configured internally when it comes to
hardware specific information such as IRQ and registers (or mmaped
registers), bluetooth UART driver no longer needs to do it by itself. It
only requires to select the port it wants to use.
Change-Id: I5a30500f4b6f4155292609d0ed4a758f91930817
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
UART is configured statically into the driver directly and not anymore
in the board's system.c. Thus limiting the information to be scattered
into 2 files instead of 3. Then in future, it will also be possible to
remove driver specific informations from the generic UART API structure.
Change-Id: I001f2a6834df9a41ab395a80e4e39b347d545db3
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Now for x86 platforms, UART is configured statically or dynamically into
the driver and not anymore in the board's system.c. Thus limiting the
information to be scattered into 2 files instead of 3. Then in future,
it will also be possible to remove driver specific informations from the
generic UART API structure.
Change-Id: I7b7fa37f10f88316a4d375c99de3bbacf152a3e3
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
By default it is set to 'n'. This will be useful to enable the PCI layer
code if required. On quark boark, it is selected by default as UART
driver needs it currently.
Change-Id: I7aa38e73c431c66ebbd8092aff0a14d5fb9268d5
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Remove camel case style on baseAddr, changing it into base.
Change-Id: Iea1e2d204a38912f4157cc6776a88640e29a04f6
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Using "which" is somehow awkward to use when 'port', on the contrary, is
blatantly more readable.
Change-Id: I355c6e09d7c27b4b07ab6cd10b772a632855516b
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Using "which" is somehow awkward to use when 'port', on the contrary, is
blatantly more readable.
Change-Id: Id4d3786a192a650ca042024521b94e557a3ec7e8
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Just a tiny change s/which/port.
Change-Id: I69be83f9805d71f5ec0ad68b146816d2a4fe221a
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
It is useless as PCI scanning is now storing anything.
Change-Id: I6e3b1e328e2f440ac57a2142cab138e4a222f4fc
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
This fixes many issues around PCI enumeration from old API:
- a static internal table was fed with scanning results, thus eating
memory, and worse: due to the limit of its size, scanning for new
classes was impossible unless growing statically the size of this
table --> more memory eaten! Not to mention PCI enumeration is done
once at boot time for driver initialization and that's all, so this
table is hanging around for nothing afterwards.
- one needs first to scan a class, then maybe he will be able to find
his device via pci_dev_find. Where all could be done at once.
- pci_dev_find was not trustworthy due again to the internal table. Now
if the device is not found, one will know it really went through all
the possbilities.
- still let the possibility for hard-coded BARs value on driver side
(thus no PCI scan required). However this is greatly advised not to do
so as BARs might change over a firmware/BIOS update.
Comparison:
old pci_dev_scan: could only filter out via class mask.
new pci_dev_scan: can filter out via a class, a vendor and device ID
(it could easily do the same for Function and BAR index as these are
usually fixed and informed through datasheet)
old pci_dev_scan: was limited in its findings by the size of the
internal result table.
new pci_dev_scan: can proceed through all the buses and devices every
time (there are optimizations to avoid useless work of course)
old results did not tell about the function or BAR index.
new one tells, and the structure has not bloated.
old internal code: was storing a big table of results
new internal code: is only storing a small lookup structure and an
array of Bus:Dev pairs for each PCI class for optimizations purpose.
(though, if needed, we could disable this through some #ifdef)
Usage:
- Have a local struct dev_info
- Fill it with what you want to look for, currently: only class and
vendor_id/device_id. Function and BAR index could be added if needed.
- Call pci_bus_scan_init(): this will reset the internal lookup
structure.
- Call pci_dev_scan(<a pointer to your dev_info>): at first call, the
internal lookup structure will pick up the informations from dev_info
and will try to find out what has been requested. It will return 1 on
success, or 0. On 1, your dev_info structure will be updated with the
found informations. If more devices can be found against the same
lookup informations, just call again pci_dev_scan(<a pointer to your
dev_info>) as long as it returns 1. When 0 is hit, it will mean you
found all.
Change-Id: Ibc2a16c4485ee3fed7ef4946af0ece032ae406e4
Signed-off-by: Tomasz Bursztyka <tomasz.bursztyka@linux.intel.com>
Building zconf.hash.c fails with gcc 5.1.1 from Fedora 22:
In file included from zconf.tab.c:159:0:
zconf.hash.c:233:55: error: ‘kconf_id_strings_contents’ is static but used in inline function ‘kconf_id_lookup’ which is not static [-Werror]
zconf.hash.c:226:23: error: ‘kconf_id_hash’ is static but used in inline function ‘kconf_id_lookup’ which is not static [-Werror]
register int key = kconf_id_hash (str, len);
^
zconf.hash.c:177:26: error: ‘wordlist’ is static but declared in inline function ‘kconf_id_lookup’ which is not static [-Werror]
static struct kconf_id wordlist[] =
^
Import the necessary change from the latest Linux source tree.
Change-Id: Ib6297b5cc3da161bd99c2e92c366206e6c08b4e5
Signed-off-by: Johan Hedberg <johan.hedberg@intel.com>
- Fix missing spaces between package names
- Move optional software to its own section, no need to have
it in the main requirement section if it is options
- crosstool-NG instead of crosstool-next Generation. Treat that
as a brand name.
- Fixed command line for installing groups with yum
- minor fixes
Change-Id: Ib231bb09dea3aa6d3af00961eae8a2e3d6ded011
Signed-off-by: Anas Nashif <anas.nashif@intel.com>
Includes the Collaboration Guideline. It contains the infromation
regarding the use of the mailing list, Gerrit, the coding style and
other usefull collaboration information.
This Collaboration Guideline is constantly changing as new methods of
collaboration are used.
Change-Id: I9f1e66556e99defa8729f87f19052b539e8628d3
Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>
Includes the Linux Installation Guide. It contains the requirements and
required steps to install a development environment and to run a sample
application. The optional steps include information regarding running
Tiny Mountain on additional hardware.
Change-Id: I0f0c78fbec6816310d893b40dea5649ead98e92f
Signed-off-by: Rodrigo Caballero <rodrigo.caballero.abraham@intel.com>
Several pipe buffer definitions now reside with the other
pipe buffer code. (One routine is also made non-global,
since it only referenced by the pipe buffer code itself.)
Change-Id: I76785d113edd62c9626a7116c9206472656128ec
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
1) Re-orders routines to eliminate the need for forward referencing.
2) Makes routines non-global if they are only referenced by pipe
buffer code itself.
3) Optimizes out an unnecessary wrapper routine.
Change-Id: I731db9c9125c58d98c5e350bdd1708456e2cf40c
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
Brings file names into alignment with current naming conventions,
and relocates them to the main microkernel directory.
Note: Since the microkernel/channel directory is now empty, the
build system no longer attempts to build its contents.
Change-Id: I936c7cdf2e08f675dd66a87cacf3b4fa5a7a6441
Signed-off-by: Allan Stephens <allan.stephens@windriver.com>
