From: Ilya Faenson <ifaenson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
To: Rob Herring <robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: "marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org"
<marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org>,
Arend Van Spriel <arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>,
"devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>,
"linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org"
<linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org>
Subject: RE: FW: [PATCH v4 1/4] Broadcom Bluetooth UART Device Tree bindings
Date: Fri, 19 Jun 2015 20:37:32 +0000 [thread overview]
Message-ID: <E0D3336E15B58B4294723AC879BA5E94264862@IRVEXCHMB15.corp.ad.broadcom.com> (raw)
In-Reply-To: <CAL_JsqJKyj8sDwG82jb_CzXEDBN8aznR7eF5yTOiWruW8o3cng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Hi Rob,
-----Original Message-----
From: Rob Herring [mailto:robherring2@gmail.com]
Sent: Friday, June 19, 2015 11:48 AM
To: Ilya Faenson
Cc: marcel@holtmann.org; Arend Van Spriel; devicetree@vger.kernel.org; linux-bluetooth@vger.kernel.org
Subject: Re: FW: [PATCH v4 1/4] Broadcom Bluetooth UART Device Tree bindings
On Thu, Jun 18, 2015 at 3:37 PM, Ilya Faenson <ifaenson@broadcom.com> wrote:
> Hi Rob.
>
> -----Original Message-----
> From: linux-bluetooth-owner@vger.kernel.org [mailto:linux-bluetooth-owner@vger.kernel.org] On Behalf Of Rob Herring
> Sent: Thursday, June 18, 2015 3:41 PM
> To: Ilya Faenson
> Cc: marcel@holtmann.org; Arend Van Spriel; devicetree@vger.kernel.org; linux-bluetooth@vger.kernel.org
> Subject: Re: FW: [PATCH v4 1/4] Broadcom Bluetooth UART Device Tree bindings
>
> On Thu, Jun 18, 2015 at 1:54 PM, Ilya Faenson <ifaenson@broadcom.com> wrote:
>> Hi Rob,
>
> Your emails are base64 encoded. They should be plain text for the list.
>
> IF: The Outlook is configured to respond in the sender's format. I therefore respond in the encoding you've used.
I assure you that that is not the case or I would be banished from
lists by now. Outlook is generally incapable of correctly sending
mails to lists. The reply header above is one aspect of that. The
other problem is your replies don't get wrapped and prefixed properly.
That could be my client I guess, but *all* other mails are fine.
My sent mails have:
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
IF: Unluckily, Outlook is what I am supposed to use. I post patches from the Ubuntu VM but I have the command line access to it only.
>> -----Original Message-----
>> From: Rob Herring [mailto:robherring2@gmail.com]
>> Sent: Thursday, June 18, 2015 11:03 AM
>> To: Ilya Faenson
>> Cc: marcel@holtmann.org; Arend Van Spriel; devicetree@vger.kernel.org; linux-bluetooth@vger.kernel.org
>> Subject: Re: FW: [PATCH v4 1/4] Broadcom Bluetooth UART Device Tree bindings
>>
>> On Wed, Jun 17, 2015 at 6:11 PM, Ilya Faenson <ifaenson@broadcom.com> wrote:
>>> + devicetree lists
>
> [...]
>
>>> diff --git a/Documentation/devicetree/bindings/net/bluetooth/btbcm.txt b/Documentation/devicetree/bindings/net/bluetooth/btbcm.txt
>>> new file mode 100644
>>> index 0000000..5dbcd57
>>> --- /dev/null
>>> +++ b/Documentation/devicetree/bindings/net/bluetooth/btbcm.txt
>>> @@ -0,0 +1,86 @@
>>> +btbcm
>>> +------
>>> +
>>> +Required properties:
>>> +
>>> + - compatible : must be "brcm,brcm-bt-uart".
>>
>> You need to describe the chip, not the interface.
>>
>> IF: This driver is for all Broadcom Bluetooth UART based chips.
>
> BT only chips? Most/many Broadcom chips are combo chips. I understand
> the driver for BT is *mostly* separate from other chip functions like
> WiFi, GPS and NFC, but the h/w is a single chip. I say most because
> likely there are some parts shared: a voltage rail, reset line, or
> power down line. I think some can do BT over the SDIO interface too,
> so the interface may be shared. The DT is a description of the h/w
> (i.e. what part # for a chip) and not a driver data structure. You
> need to describe the whole chip in the binding. It is a Linux problem
> if there needs to be multiple separate drivers.
>
> IF: Defining complete DT description for the Broadcom combo chips for multiple interfaces is well beyond the scope of what I am doing. I just need to define a DT node for the input and output GPIOs connected to the BT UART chip. BT may or may not be part of the combo chip: it does not really matter for this exercise. I thought I would take this opportunity to place some BT device parameters into that node as well. If you're not comfortable with this, I could just call it a "GPIO set" to avoid mentioning BT and UART at all but it would make little sense. Still, I could consider it. Would you have "GPIO set" recommendations? Alternatively, NFC Marvell code you're referring to has parameters configured as Linux module parameters. I could do the same too, avoiding this device tree discussion. Let me know.
>
I don't completely follow what you mean by "GPIO set", but I'm
guessing that is not the right path.
> Generally speaking (pontification hat on :-)), what you're trying to do (description of the whole chip) is well beyond what say ACPI has done (I was involved some in the BT ACPI exercise a few years ago). BT UART interface is described in ACPI independently of other parts of the same combo chip. Requirements like that slow down the DT development in my opinion as companies are understandably reluctant to work with unrealistic goals. End of pontification. :-)
>
ACPI and DT are very different models in terms of abstraction and
governance. I'm not going to hash through all the details.
I'm not necessarily saying we have to have a single node, but that is
my default position. You have convince me that the functions are
completely independent and I cannot judge that if you are completely
ignoring the WiFi part. From Broadcom chips I've worked with, the
supplies at least are shared (something ACPI does not expose). Perhaps
we could fudge that and just require the same supply has to be
connected to each half. I still worry there could be other internal
inter-dependencies. Perhaps BT requires the SDIO clock to be active or
something like that. Maybe not on Broadcom chips, but on other vendors
and I have to care about them all.
Let's step back to what I'm asking for:
- A more specific compatible string. This should include the chip
name/number. You may not need it today, but it is insurance in case
you do find differences latter. The only impact is the match table in
your driver. You can also have a less specific compatible string if
you want that the driver can match on.
IF: Okay, I can change that.
- Changing the location of the node. The node hierarchy implicitly
defines connections. You have a connection from the host UART to the
BT device. This needs to be described. Whether splitting BT and WiFi
nodes or not, I've already said it probably makes the most sense to
put this under the host uart node.
IF: Okay, I have just tried placing my node under the UART. The platform driver probe is no longer called then though. What am I doing wrong? Pasting the relevant snippet:
IF: &uart1 {
IF: status = "okay";
IF: ...
IF: bcm4354_bt_uart: bcm4354-bt-uart {
IF: compatible = "brcm,brcm4354-bt-uart";
IF: bt-wake-gpios = <&gpio4 30 GPIO_ACTIVE_HIGH>;
IF: ...
IF: };
IF: };
- Splitting the nodes. Here we are looking at doing either:
serial@1234 {
compatible = "some-soc-uart";
brcm43340 {
compatible = "brcm,brcm43340";
sdio-host = <&soc-sdhost>;
// BT props
// WiFi props
};
};
Or:
serial@1234 {
compatible = "some-soc-uart";
brcm43340 {
compatible = "brcm,brcm43340-bt";
// BT props
};
};
mmc@5678 {
compatible = "some-soc-sdhci";
brcm43340@0 {
reg = <0>;
compatible = "brcm,brcm43340-wifi";
// WiFi props
};
};
Or maybe it is the latter example but we just add phandle links
between the 2 nodes.
We haven't even considered what happens when a chip also has FM, NFC,
and/or GPS. Nor have we considered how to describe the audio
connection to the host processor, but we've got nothing common and
that can probably come latter.
We need to agree figuring all this out is needed. Otherwise, this
whole conversation is a waste of time.
IF: Appreciate the detailed elaborations. The latter example with phandle links sounds reasonable to me. I am afraid I'm not in a position to agree to everything though as I'm responsible for the BT only. Arend Van Spriel representing Broadcom WLAN has started talking to you: that's good.
>>
>>> + - tty : tty device connected to this Bluetooth device.
>>
>> "tty" is a bit of a Linuxism and "ttyS0" certainly is. Further, there
>> is no guarantee which uart is assigned ttyS0.
>>
>> This should be a phandle to the connected uart if not a sub node of
>> the uart. This is complicated since these chips have multiple host
>> connections. It needs to go under either uart or SDIO host and have a
>> reference back to the one it is not under. Given the SDIO interface is
>> discoverable (although sideband gpios and regulators are not), I would
>> put this under the uart node as that is never discoverable.
>>
>> As I've mentioned previously, there's several cases of bindings for
>> UART slave devices being posted. This all needs to be coordinated to
>> use a common structure.
>>
>> IF: This driver does not really access the UART. If just needs to have a string of some sort to map instances of the BlueZ protocol into platform devices to employ the right GPIOs and interrupts. I could use anything you recommend available through the tty_struct coming to the protocol from the BlueZ line discipline. Moreover, every end user platform I've ever dealt with in 16 years of working with Bluetooth had a single BT UART device. So these are really rare (typically test platforms) cases only. The mapping is not needed for most platforms at all. I suspect the right thing to do would be to make this parameter optional. The mapping would be done only if the parameter is present. I will use anything tty_struct derived you specify. Makes sense?
>
>
> You've missed my point. I'm not talking about connecting multiple
> devices to a UART at once. There are several instances of people
> trying to add UART connected devices into DT[1][2]. My point is these
> devices all need to have the DT binding done in a common way across
> different platforms. Otherwise, we can not have common code to parse
> the DT and find devices attached to a UART.
>
> IF: Chances are I was not clear enough. I was not talking about connecting multiple devices to a UART. I was talking about connecting one Broadcom BT device to one serial port and another Broadcom BT device to another serial port (rare enough setup). I do understand your goals though. I would be happy to participate in that exercise (subject to the management approval) once DT has published the UART device parameters and the Linux bluetooth-next has support for DT enumerated devices. I don’t see it happening soon though. Marvell example you've referred me to has nothing of the sort. What do you think of allowing us something to ship now with an understanding that we would support your UART enumerated devices once they are published?
Okay. Several people want to describe a connection between a host uart
and a device connected to the uart (BT, NFC, GPS, etc.). You are doing
this with your "tty" property. My goal and requirement is that this
connection be described in DT in the same way regardless of the device
attached. Just like all I2C device connections are described by being
child nodes under the I2C host regardless of the type of I2C device
attached.
IF: All good points, Rob. I will certainly get rid of the tty property if I can make the child device idea work. My complication is in the need to map say the DT device parent (UART) into the tty_struct used by the Linux BlueZ protocol. Any ideas on how to implement that ? Many thanks!
Rob
WARNING: multiple messages have this Message-ID (diff)
From: Ilya Faenson <ifaenson@broadcom.com>
To: Rob Herring <robherring2@gmail.com>
Cc: "marcel@holtmann.org" <marcel@holtmann.org>,
Arend Van Spriel <arend@broadcom.com>,
"devicetree@vger.kernel.org" <devicetree@vger.kernel.org>,
"linux-bluetooth@vger.kernel.org"
<linux-bluetooth@vger.kernel.org>
Subject: RE: FW: [PATCH v4 1/4] Broadcom Bluetooth UART Device Tree bindings
Date: Fri, 19 Jun 2015 20:37:32 +0000 [thread overview]
Message-ID: <E0D3336E15B58B4294723AC879BA5E94264862@IRVEXCHMB15.corp.ad.broadcom.com> (raw)
In-Reply-To: <CAL_JsqJKyj8sDwG82jb_CzXEDBN8aznR7eF5yTOiWruW8o3cng@mail.gmail.com>
SGkgUm9iLA0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KRnJvbTogUm9iIEhlcnJpbmcg
W21haWx0bzpyb2JoZXJyaW5nMkBnbWFpbC5jb21dIA0KU2VudDogRnJpZGF5LCBKdW5lIDE5LCAy
MDE1IDExOjQ4IEFNDQpUbzogSWx5YSBGYWVuc29uDQpDYzogbWFyY2VsQGhvbHRtYW5uLm9yZzsg
QXJlbmQgVmFuIFNwcmllbDsgZGV2aWNldHJlZUB2Z2VyLmtlcm5lbC5vcmc7IGxpbnV4LWJsdWV0
b290aEB2Z2VyLmtlcm5lbC5vcmcNClN1YmplY3Q6IFJlOiBGVzogW1BBVENIIHY0IDEvNF0gQnJv
YWRjb20gQmx1ZXRvb3RoIFVBUlQgRGV2aWNlIFRyZWUgYmluZGluZ3MNCg0KT24gVGh1LCBKdW4g
MTgsIDIwMTUgYXQgMzozNyBQTSwgSWx5YSBGYWVuc29uIDxpZmFlbnNvbkBicm9hZGNvbS5jb20+
IHdyb3RlOg0KPiBIaSBSb2IuDQo+DQo+IC0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+IEZy
b206IGxpbnV4LWJsdWV0b290aC1vd25lckB2Z2VyLmtlcm5lbC5vcmcgW21haWx0bzpsaW51eC1i
bHVldG9vdGgtb3duZXJAdmdlci5rZXJuZWwub3JnXSBPbiBCZWhhbGYgT2YgUm9iIEhlcnJpbmcN
Cj4gU2VudDogVGh1cnNkYXksIEp1bmUgMTgsIDIwMTUgMzo0MSBQTQ0KPiBUbzogSWx5YSBGYWVu
c29uDQo+IENjOiBtYXJjZWxAaG9sdG1hbm4ub3JnOyBBcmVuZCBWYW4gU3ByaWVsOyBkZXZpY2V0
cmVlQHZnZXIua2VybmVsLm9yZzsgbGludXgtYmx1ZXRvb3RoQHZnZXIua2VybmVsLm9yZw0KPiBT
dWJqZWN0OiBSZTogRlc6IFtQQVRDSCB2NCAxLzRdIEJyb2FkY29tIEJsdWV0b290aCBVQVJUIERl
dmljZSBUcmVlIGJpbmRpbmdzDQo+DQo+IE9uIFRodSwgSnVuIDE4LCAyMDE1IGF0IDE6NTQgUE0s
IElseWEgRmFlbnNvbiA8aWZhZW5zb25AYnJvYWRjb20uY29tPiB3cm90ZToNCj4+IEhpIFJvYiwN
Cj4NCj4gWW91ciBlbWFpbHMgYXJlIGJhc2U2NCBlbmNvZGVkLiBUaGV5IHNob3VsZCBiZSBwbGFp
biB0ZXh0IGZvciB0aGUgbGlzdC4NCj4NCj4gSUY6IFRoZSBPdXRsb29rIGlzIGNvbmZpZ3VyZWQg
dG8gcmVzcG9uZCBpbiB0aGUgc2VuZGVyJ3MgZm9ybWF0LiBJIHRoZXJlZm9yZSByZXNwb25kIGlu
IHRoZSBlbmNvZGluZyB5b3UndmUgdXNlZC4NCg0KSSBhc3N1cmUgeW91IHRoYXQgdGhhdCBpcyBu
b3QgdGhlIGNhc2Ugb3IgSSB3b3VsZCBiZSBiYW5pc2hlZCBmcm9tDQpsaXN0cyBieSBub3cuIE91
dGxvb2sgaXMgZ2VuZXJhbGx5IGluY2FwYWJsZSBvZiBjb3JyZWN0bHkgc2VuZGluZw0KbWFpbHMg
dG8gbGlzdHMuIFRoZSByZXBseSBoZWFkZXIgYWJvdmUgaXMgb25lIGFzcGVjdCBvZiB0aGF0LiBU
aGUNCm90aGVyIHByb2JsZW0gaXMgeW91ciByZXBsaWVzIGRvbid0IGdldCB3cmFwcGVkIGFuZCBw
cmVmaXhlZCBwcm9wZXJseS4NClRoYXQgY291bGQgYmUgbXkgY2xpZW50IEkgZ3Vlc3MsIGJ1dCAq
YWxsKiBvdGhlciBtYWlscyBhcmUgZmluZS4NCg0KTXkgc2VudCBtYWlscyBoYXZlOg0KDQpDb250
ZW50LVR5cGU6IHRleHQvcGxhaW47IGNoYXJzZXQ9VVRGLTgNCkNvbnRlbnQtVHJhbnNmZXItRW5j
b2Rpbmc6IHF1b3RlZC1wcmludGFibGUNCg0KSUY6IFVubHVja2lseSwgT3V0bG9vayBpcyB3aGF0
IEkgYW0gc3VwcG9zZWQgdG8gdXNlLiBJIHBvc3QgcGF0Y2hlcyBmcm9tIHRoZSBVYnVudHUgVk0g
YnV0IEkgaGF2ZSB0aGUgY29tbWFuZCBsaW5lIGFjY2VzcyB0byBpdCBvbmx5Lg0KDQo+PiAtLS0t
LU9yaWdpbmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogUm9iIEhlcnJpbmcgW21haWx0bzpyb2Jo
ZXJyaW5nMkBnbWFpbC5jb21dDQo+PiBTZW50OiBUaHVyc2RheSwgSnVuZSAxOCwgMjAxNSAxMTow
MyBBTQ0KPj4gVG86IElseWEgRmFlbnNvbg0KPj4gQ2M6IG1hcmNlbEBob2x0bWFubi5vcmc7IEFy
ZW5kIFZhbiBTcHJpZWw7IGRldmljZXRyZWVAdmdlci5rZXJuZWwub3JnOyBsaW51eC1ibHVldG9v
dGhAdmdlci5rZXJuZWwub3JnDQo+PiBTdWJqZWN0OiBSZTogRlc6IFtQQVRDSCB2NCAxLzRdIEJy
b2FkY29tIEJsdWV0b290aCBVQVJUIERldmljZSBUcmVlIGJpbmRpbmdzDQo+Pg0KPj4gT24gV2Vk
LCBKdW4gMTcsIDIwMTUgYXQgNjoxMSBQTSwgSWx5YSBGYWVuc29uIDxpZmFlbnNvbkBicm9hZGNv
bS5jb20+IHdyb3RlOg0KPj4+ICsgZGV2aWNldHJlZSBsaXN0cw0KPg0KPiBbLi4uXQ0KPg0KPj4+
IGRpZmYgLS1naXQgYS9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbmV0L2JsdWV0
b290aC9idGJjbS50eHQgYi9Eb2N1bWVudGF0aW9uL2RldmljZXRyZWUvYmluZGluZ3MvbmV0L2Js
dWV0b290aC9idGJjbS50eHQNCj4+PiBuZXcgZmlsZSBtb2RlIDEwMDY0NA0KPj4+IGluZGV4IDAw
MDAwMDAuLjVkYmNkNTcNCj4+PiAtLS0gL2Rldi9udWxsDQo+Pj4gKysrIGIvRG9jdW1lbnRhdGlv
bi9kZXZpY2V0cmVlL2JpbmRpbmdzL25ldC9ibHVldG9vdGgvYnRiY20udHh0DQo+Pj4gQEAgLTAs
MCArMSw4NiBAQA0KPj4+ICtidGJjbQ0KPj4+ICstLS0tLS0NCj4+PiArDQo+Pj4gK1JlcXVpcmVk
IHByb3BlcnRpZXM6DQo+Pj4gKw0KPj4+ICsgICAgICAgLSBjb21wYXRpYmxlIDogbXVzdCBiZSAi
YnJjbSxicmNtLWJ0LXVhcnQiLg0KPj4NCj4+IFlvdSBuZWVkIHRvIGRlc2NyaWJlIHRoZSBjaGlw
LCBub3QgdGhlIGludGVyZmFjZS4NCj4+DQo+PiBJRjogVGhpcyBkcml2ZXIgaXMgZm9yIGFsbCBC
cm9hZGNvbSBCbHVldG9vdGggVUFSVCBiYXNlZCBjaGlwcy4NCj4NCj4gQlQgb25seSBjaGlwcz8g
TW9zdC9tYW55IEJyb2FkY29tIGNoaXBzIGFyZSBjb21ibyBjaGlwcy4gSSB1bmRlcnN0YW5kDQo+
IHRoZSBkcml2ZXIgZm9yIEJUIGlzICptb3N0bHkqIHNlcGFyYXRlIGZyb20gb3RoZXIgY2hpcCBm
dW5jdGlvbnMgbGlrZQ0KPiBXaUZpLCBHUFMgYW5kIE5GQywgYnV0IHRoZSBoL3cgaXMgYSBzaW5n
bGUgY2hpcC4gSSBzYXkgbW9zdCBiZWNhdXNlDQo+IGxpa2VseSB0aGVyZSBhcmUgc29tZSBwYXJ0
cyBzaGFyZWQ6IGEgdm9sdGFnZSByYWlsLCByZXNldCBsaW5lLCBvcg0KPiBwb3dlciBkb3duIGxp
bmUuIEkgdGhpbmsgc29tZSBjYW4gZG8gQlQgb3ZlciB0aGUgU0RJTyBpbnRlcmZhY2UgdG9vLA0K
PiBzbyB0aGUgaW50ZXJmYWNlIG1heSBiZSBzaGFyZWQuIFRoZSBEVCBpcyBhIGRlc2NyaXB0aW9u
IG9mIHRoZSBoL3cNCj4gKGkuZS4gd2hhdCBwYXJ0ICMgZm9yIGEgY2hpcCkgYW5kIG5vdCBhIGRy
aXZlciBkYXRhIHN0cnVjdHVyZS4gWW91DQo+IG5lZWQgdG8gZGVzY3JpYmUgdGhlIHdob2xlIGNo
aXAgaW4gdGhlIGJpbmRpbmcuIEl0IGlzIGEgTGludXggcHJvYmxlbQ0KPiBpZiB0aGVyZSBuZWVk
cyB0byBiZSBtdWx0aXBsZSBzZXBhcmF0ZSBkcml2ZXJzLg0KPg0KPiBJRjogRGVmaW5pbmcgY29t
cGxldGUgRFQgZGVzY3JpcHRpb24gZm9yIHRoZSBCcm9hZGNvbSBjb21ibyBjaGlwcyBmb3IgbXVs
dGlwbGUgaW50ZXJmYWNlcyBpcyB3ZWxsIGJleW9uZCB0aGUgc2NvcGUgb2Ygd2hhdCBJIGFtIGRv
aW5nLiBJIGp1c3QgbmVlZCB0byBkZWZpbmUgYSBEVCBub2RlIGZvciB0aGUgaW5wdXQgYW5kIG91
dHB1dCBHUElPcyBjb25uZWN0ZWQgdG8gdGhlIEJUIFVBUlQgY2hpcC4gQlQgbWF5IG9yIG1heSBu
b3QgYmUgcGFydCBvZiB0aGUgY29tYm8gY2hpcDogaXQgZG9lcyBub3QgcmVhbGx5IG1hdHRlciBm
b3IgdGhpcyBleGVyY2lzZS4gSSB0aG91Z2h0IEkgd291bGQgdGFrZSB0aGlzIG9wcG9ydHVuaXR5
IHRvIHBsYWNlIHNvbWUgQlQgZGV2aWNlIHBhcmFtZXRlcnMgaW50byB0aGF0IG5vZGUgYXMgd2Vs
bC4gSWYgeW91J3JlIG5vdCBjb21mb3J0YWJsZSB3aXRoIHRoaXMsIEkgY291bGQganVzdCBjYWxs
IGl0IGEgIkdQSU8gc2V0IiB0byBhdm9pZCBtZW50aW9uaW5nIEJUIGFuZCBVQVJUIGF0IGFsbCBi
dXQgaXQgd291bGQgbWFrZSBsaXR0bGUgc2Vuc2UuIFN0aWxsLCBJIGNvdWxkIGNvbnNpZGVyIGl0
LiBXb3VsZCB5b3UgaGF2ZSAiR1BJTyBzZXQiIHJlY29tbWVuZGF0aW9ucz8gQWx0ZXJuYXRpdmVs
eSwgTkZDIE1hcnZlbGwgY29kZSB5b3UncmUgcmVmZXJyaW5nIHRvIGhhcyBwYXJhbWV0ZXJzIGNv
bmZpZ3VyZWQgYXMgTGludXggbW9kdWxlIHBhcmFtZXRlcnMuIEkgY291bGQgZG8gdGhlIHNhbWUg
dG9vLCBhdm9pZGluZyB0aGlzIGRldmljZSB0cmVlIGRpc2N1c3Npb24uIExldCBtZSBrbm93Lg0K
Pg0KDQpJIGRvbid0IGNvbXBsZXRlbHkgZm9sbG93IHdoYXQgeW91IG1lYW4gYnkgIkdQSU8gc2V0
IiwgYnV0IEknbQ0KZ3Vlc3NpbmcgdGhhdCBpcyBub3QgdGhlIHJpZ2h0IHBhdGguDQoNCj4gR2Vu
ZXJhbGx5IHNwZWFraW5nIChwb250aWZpY2F0aW9uIGhhdCBvbiA6LSkpLCB3aGF0IHlvdSdyZSB0
cnlpbmcgdG8gZG8gKGRlc2NyaXB0aW9uIG9mIHRoZSB3aG9sZSBjaGlwKSBpcyB3ZWxsIGJleW9u
ZCB3aGF0IHNheSBBQ1BJIGhhcyBkb25lIChJIHdhcyBpbnZvbHZlZCBzb21lIGluIHRoZSBCVCBB
Q1BJIGV4ZXJjaXNlIGEgZmV3IHllYXJzIGFnbykuIEJUIFVBUlQgaW50ZXJmYWNlIGlzIGRlc2Ny
aWJlZCBpbiBBQ1BJIGluZGVwZW5kZW50bHkgb2Ygb3RoZXIgcGFydHMgb2YgdGhlIHNhbWUgY29t
Ym8gY2hpcC4gUmVxdWlyZW1lbnRzIGxpa2UgdGhhdCBzbG93IGRvd24gdGhlIERUIGRldmVsb3Bt
ZW50IGluIG15IG9waW5pb24gYXMgY29tcGFuaWVzIGFyZSB1bmRlcnN0YW5kYWJseSByZWx1Y3Rh
bnQgdG8gd29yayB3aXRoIHVucmVhbGlzdGljIGdvYWxzLiBFbmQgb2YgcG9udGlmaWNhdGlvbi4g
Oi0pDQo+DQoNCkFDUEkgYW5kIERUIGFyZSB2ZXJ5IGRpZmZlcmVudCBtb2RlbHMgaW4gdGVybXMg
b2YgYWJzdHJhY3Rpb24gYW5kDQpnb3Zlcm5hbmNlLiBJJ20gbm90IGdvaW5nIHRvIGhhc2ggdGhy
b3VnaCBhbGwgdGhlIGRldGFpbHMuDQoNCkknbSBub3QgbmVjZXNzYXJpbHkgc2F5aW5nIHdlIGhh
dmUgdG8gaGF2ZSBhIHNpbmdsZSBub2RlLCBidXQgdGhhdCBpcw0KbXkgZGVmYXVsdCBwb3NpdGlv
bi4gWW91IGhhdmUgY29udmluY2UgbWUgdGhhdCB0aGUgZnVuY3Rpb25zIGFyZQ0KY29tcGxldGVs
eSBpbmRlcGVuZGVudCBhbmQgSSBjYW5ub3QganVkZ2UgdGhhdCBpZiB5b3UgYXJlIGNvbXBsZXRl
bHkNCmlnbm9yaW5nIHRoZSBXaUZpIHBhcnQuIEZyb20gQnJvYWRjb20gY2hpcHMgSSd2ZSB3b3Jr
ZWQgd2l0aCwgdGhlDQpzdXBwbGllcyBhdCBsZWFzdCBhcmUgc2hhcmVkIChzb21ldGhpbmcgQUNQ
SSBkb2VzIG5vdCBleHBvc2UpLiBQZXJoYXBzDQp3ZSBjb3VsZCBmdWRnZSB0aGF0IGFuZCBqdXN0
IHJlcXVpcmUgdGhlIHNhbWUgc3VwcGx5IGhhcyB0byBiZQ0KY29ubmVjdGVkIHRvIGVhY2ggaGFs
Zi4gSSBzdGlsbCB3b3JyeSB0aGVyZSBjb3VsZCBiZSBvdGhlciBpbnRlcm5hbA0KaW50ZXItZGVw
ZW5kZW5jaWVzLiBQZXJoYXBzIEJUIHJlcXVpcmVzIHRoZSBTRElPIGNsb2NrIHRvIGJlIGFjdGl2
ZSBvcg0Kc29tZXRoaW5nIGxpa2UgdGhhdC4gTWF5YmUgbm90IG9uIEJyb2FkY29tIGNoaXBzLCBi
dXQgb24gb3RoZXIgdmVuZG9ycw0KYW5kIEkgaGF2ZSB0byBjYXJlIGFib3V0IHRoZW0gYWxsLg0K
DQpMZXQncyBzdGVwIGJhY2sgdG8gd2hhdCBJJ20gYXNraW5nIGZvcjoNCg0KLSBBIG1vcmUgc3Bl
Y2lmaWMgY29tcGF0aWJsZSBzdHJpbmcuIFRoaXMgc2hvdWxkIGluY2x1ZGUgdGhlIGNoaXANCm5h
bWUvbnVtYmVyLiBZb3UgbWF5IG5vdCBuZWVkIGl0IHRvZGF5LCBidXQgaXQgaXMgaW5zdXJhbmNl
IGluIGNhc2UNCnlvdSBkbyBmaW5kIGRpZmZlcmVuY2VzIGxhdHRlci4gVGhlIG9ubHkgaW1wYWN0
IGlzIHRoZSBtYXRjaCB0YWJsZSBpbg0KeW91ciBkcml2ZXIuIFlvdSBjYW4gYWxzbyBoYXZlIGEg
bGVzcyBzcGVjaWZpYyBjb21wYXRpYmxlIHN0cmluZyBpZg0KeW91IHdhbnQgdGhhdCB0aGUgZHJp
dmVyIGNhbiBtYXRjaCBvbi4NCg0KSUY6IE9rYXksIEkgY2FuIGNoYW5nZSB0aGF0Lg0KDQotIENo
YW5naW5nIHRoZSBsb2NhdGlvbiBvZiB0aGUgbm9kZS4gVGhlIG5vZGUgaGllcmFyY2h5IGltcGxp
Y2l0bHkNCmRlZmluZXMgY29ubmVjdGlvbnMuIFlvdSBoYXZlIGEgY29ubmVjdGlvbiBmcm9tIHRo
ZSBob3N0IFVBUlQgdG8gdGhlDQpCVCBkZXZpY2UuIFRoaXMgbmVlZHMgdG8gYmUgZGVzY3JpYmVk
LiBXaGV0aGVyIHNwbGl0dGluZyBCVCBhbmQgV2lGaQ0Kbm9kZXMgb3Igbm90LCBJJ3ZlIGFscmVh
ZHkgc2FpZCBpdCBwcm9iYWJseSBtYWtlcyB0aGUgbW9zdCBzZW5zZSB0bw0KcHV0IHRoaXMgdW5k
ZXIgdGhlIGhvc3QgdWFydCBub2RlLg0KDQpJRjogT2theSwgSSBoYXZlIGp1c3QgdHJpZWQgcGxh
Y2luZyBteSBub2RlIHVuZGVyIHRoZSBVQVJULiBUaGUgcGxhdGZvcm0gZHJpdmVyIHByb2JlIGlz
IG5vIGxvbmdlciBjYWxsZWQgdGhlbiB0aG91Z2guIFdoYXQgYW0gSSBkb2luZyB3cm9uZz8gUGFz
dGluZyB0aGUgcmVsZXZhbnQgc25pcHBldDoNCg0KSUY6ICZ1YXJ0MSB7DQpJRjogICAgICAgICBz
dGF0dXMgPSAib2theSI7DQpJRjogICAgICAgICAuLi4NCklGOiAgICAgICAgIGJjbTQzNTRfYnRf
dWFydDogYmNtNDM1NC1idC11YXJ0IHsNCklGOiAgICAgICAgICAgICAgICAgY29tcGF0aWJsZSA9
ICJicmNtLGJyY200MzU0LWJ0LXVhcnQiOw0KSUY6ICAgICAgICAgICAgICAgICBidC13YWtlLWdw
aW9zID0gPCZncGlvNCAzMCBHUElPX0FDVElWRV9ISUdIPjsNCklGOiAgICAgICAgICAgICAgICAg
Li4uDQpJRjogICAgICAgICB9Ow0KSUY6IH07DQoNCi0gU3BsaXR0aW5nIHRoZSBub2Rlcy4gSGVy
ZSB3ZSBhcmUgbG9va2luZyBhdCBkb2luZyBlaXRoZXI6DQoNCnNlcmlhbEAxMjM0IHsNCiAgY29t
cGF0aWJsZSA9ICJzb21lLXNvYy11YXJ0IjsNCg0KICBicmNtNDMzNDAgew0KICAgIGNvbXBhdGli
bGUgPSAiYnJjbSxicmNtNDMzNDAiOw0KICAgIHNkaW8taG9zdCA9IDwmc29jLXNkaG9zdD47DQog
ICAgLy8gQlQgcHJvcHMNCiAgICAvLyBXaUZpIHByb3BzDQogIH07DQp9Ow0KDQpPcjoNCg0Kc2Vy
aWFsQDEyMzQgew0KICBjb21wYXRpYmxlID0gInNvbWUtc29jLXVhcnQiOw0KDQogIGJyY200MzM0
MCB7DQogICAgY29tcGF0aWJsZSA9ICJicmNtLGJyY200MzM0MC1idCI7DQogICAgLy8gQlQgcHJv
cHMNCiAgfTsNCn07DQoNCm1tY0A1Njc4IHsNCiAgY29tcGF0aWJsZSA9ICJzb21lLXNvYy1zZGhj
aSI7DQoNCiAgYnJjbTQzMzQwQDAgew0KICAgIHJlZyA9IDwwPjsNCiAgICBjb21wYXRpYmxlID0g
ImJyY20sYnJjbTQzMzQwLXdpZmkiOw0KICAgIC8vIFdpRmkgcHJvcHMNCiAgfTsNCn07DQoNCk9y
IG1heWJlIGl0IGlzIHRoZSBsYXR0ZXIgZXhhbXBsZSBidXQgd2UganVzdCBhZGQgcGhhbmRsZSBs
aW5rcw0KYmV0d2VlbiB0aGUgMiBub2Rlcy4NCg0KV2UgaGF2ZW4ndCBldmVuIGNvbnNpZGVyZWQg
d2hhdCBoYXBwZW5zIHdoZW4gYSBjaGlwIGFsc28gaGFzIEZNLCBORkMsDQphbmQvb3IgR1BTLiBO
b3IgaGF2ZSB3ZSBjb25zaWRlcmVkIGhvdyB0byBkZXNjcmliZSB0aGUgYXVkaW8NCmNvbm5lY3Rp
b24gdG8gdGhlIGhvc3QgcHJvY2Vzc29yLCBidXQgd2UndmUgZ290IG5vdGhpbmcgY29tbW9uIGFu
ZA0KdGhhdCBjYW4gcHJvYmFibHkgY29tZSBsYXR0ZXIuDQoNCldlIG5lZWQgdG8gYWdyZWUgZmln
dXJpbmcgYWxsIHRoaXMgb3V0IGlzIG5lZWRlZC4gT3RoZXJ3aXNlLCB0aGlzDQp3aG9sZSBjb252
ZXJzYXRpb24gaXMgYSB3YXN0ZSBvZiB0aW1lLg0KDQpJRjogQXBwcmVjaWF0ZSB0aGUgZGV0YWls
ZWQgZWxhYm9yYXRpb25zLiBUaGUgbGF0dGVyIGV4YW1wbGUgd2l0aCBwaGFuZGxlIGxpbmtzIHNv
dW5kcyByZWFzb25hYmxlIHRvIG1lLiBJIGFtIGFmcmFpZCBJJ20gbm90IGluIGEgcG9zaXRpb24g
dG8gYWdyZWUgdG8gZXZlcnl0aGluZyB0aG91Z2ggYXMgSSdtIHJlc3BvbnNpYmxlIGZvciB0aGUg
QlQgb25seS4gQXJlbmQgVmFuIFNwcmllbCByZXByZXNlbnRpbmcgQnJvYWRjb20gV0xBTiBoYXMg
c3RhcnRlZCB0YWxraW5nIHRvIHlvdTogdGhhdCdzIGdvb2QuDQoNCj4+DQo+Pj4gKyAgICAgICAt
IHR0eSA6IHR0eSBkZXZpY2UgY29ubmVjdGVkIHRvIHRoaXMgQmx1ZXRvb3RoIGRldmljZS4NCj4+
DQo+PiAidHR5IiBpcyBhIGJpdCBvZiBhIExpbnV4aXNtIGFuZCAidHR5UzAiIGNlcnRhaW5seSBp
cy4gRnVydGhlciwgdGhlcmUNCj4+IGlzIG5vIGd1YXJhbnRlZSB3aGljaCB1YXJ0IGlzIGFzc2ln
bmVkIHR0eVMwLg0KPj4NCj4+IFRoaXMgc2hvdWxkIGJlIGEgcGhhbmRsZSB0byB0aGUgY29ubmVj
dGVkIHVhcnQgaWYgbm90IGEgc3ViIG5vZGUgb2YNCj4+IHRoZSB1YXJ0LiBUaGlzIGlzIGNvbXBs
aWNhdGVkIHNpbmNlIHRoZXNlIGNoaXBzIGhhdmUgbXVsdGlwbGUgaG9zdA0KPj4gY29ubmVjdGlv
bnMuIEl0IG5lZWRzIHRvIGdvIHVuZGVyIGVpdGhlciB1YXJ0IG9yIFNESU8gaG9zdCBhbmQgaGF2
ZSBhDQo+PiByZWZlcmVuY2UgYmFjayB0byB0aGUgb25lIGl0IGlzIG5vdCB1bmRlci4gR2l2ZW4g
dGhlIFNESU8gaW50ZXJmYWNlIGlzDQo+PiBkaXNjb3ZlcmFibGUgKGFsdGhvdWdoIHNpZGViYW5k
IGdwaW9zIGFuZCByZWd1bGF0b3JzIGFyZSBub3QpLCBJIHdvdWxkDQo+PiBwdXQgdGhpcyB1bmRl
ciB0aGUgdWFydCBub2RlIGFzIHRoYXQgaXMgbmV2ZXIgZGlzY292ZXJhYmxlLg0KPj4NCj4+IEFz
IEkndmUgbWVudGlvbmVkIHByZXZpb3VzbHksIHRoZXJlJ3Mgc2V2ZXJhbCBjYXNlcyBvZiBiaW5k
aW5ncyBmb3INCj4+IFVBUlQgc2xhdmUgZGV2aWNlcyBiZWluZyBwb3N0ZWQuIFRoaXMgYWxsIG5l
ZWRzIHRvIGJlIGNvb3JkaW5hdGVkIHRvDQo+PiB1c2UgYSBjb21tb24gc3RydWN0dXJlLg0KPj4N
Cj4+IElGOiBUaGlzIGRyaXZlciBkb2VzIG5vdCByZWFsbHkgYWNjZXNzIHRoZSBVQVJULiBJZiBq
dXN0IG5lZWRzIHRvIGhhdmUgYSBzdHJpbmcgb2Ygc29tZSBzb3J0IHRvIG1hcCBpbnN0YW5jZXMg
b2YgdGhlIEJsdWVaIHByb3RvY29sIGludG8gcGxhdGZvcm0gZGV2aWNlcyB0byBlbXBsb3kgdGhl
IHJpZ2h0IEdQSU9zIGFuZCBpbnRlcnJ1cHRzLiBJIGNvdWxkIHVzZSBhbnl0aGluZyB5b3UgcmVj
b21tZW5kIGF2YWlsYWJsZSB0aHJvdWdoIHRoZSB0dHlfc3RydWN0IGNvbWluZyB0byB0aGUgcHJv
dG9jb2wgZnJvbSB0aGUgQmx1ZVogbGluZSBkaXNjaXBsaW5lLiBNb3Jlb3ZlciwgZXZlcnkgZW5k
IHVzZXIgcGxhdGZvcm0gSSd2ZSBldmVyIGRlYWx0IHdpdGggaW4gMTYgeWVhcnMgb2Ygd29ya2lu
ZyB3aXRoIEJsdWV0b290aCBoYWQgYSBzaW5nbGUgQlQgVUFSVCBkZXZpY2UuIFNvIHRoZXNlIGFy
ZSByZWFsbHkgcmFyZSAodHlwaWNhbGx5IHRlc3QgcGxhdGZvcm1zKSBjYXNlcyBvbmx5LiBUaGUg
bWFwcGluZyBpcyBub3QgbmVlZGVkIGZvciBtb3N0IHBsYXRmb3JtcyBhdCBhbGwuIEkgc3VzcGVj
dCB0aGUgcmlnaHQgdGhpbmcgdG8gZG8gd291bGQgYmUgdG8gbWFrZSB0aGlzIHBhcmFtZXRlciBv
cHRpb25hbC4gVGhlIG1hcHBpbmcgd291bGQgYmUgZG9uZSBvbmx5IGlmIHRoZSBwYXJhbWV0ZXIg
aXMgcHJlc2VudC4gSSB3aWxsIHVzZSBhbnl0aGluZyB0dHlfc3RydWN0IGRlcml2ZWQgeW91IHNw
ZWNpZnkuIE1ha2VzIHNlbnNlPw0KPg0KPg0KPiBZb3UndmUgbWlzc2VkIG15IHBvaW50LiBJJ20g
bm90IHRhbGtpbmcgYWJvdXQgY29ubmVjdGluZyBtdWx0aXBsZQ0KPiBkZXZpY2VzIHRvIGEgVUFS
VCBhdCBvbmNlLiBUaGVyZSBhcmUgc2V2ZXJhbCBpbnN0YW5jZXMgb2YgcGVvcGxlDQo+IHRyeWlu
ZyB0byBhZGQgVUFSVCBjb25uZWN0ZWQgZGV2aWNlcyBpbnRvIERUWzFdWzJdLiBNeSBwb2ludCBp
cyB0aGVzZQ0KPiBkZXZpY2VzIGFsbCBuZWVkIHRvIGhhdmUgdGhlIERUIGJpbmRpbmcgZG9uZSBp
biBhIGNvbW1vbiB3YXkgYWNyb3NzDQo+IGRpZmZlcmVudCBwbGF0Zm9ybXMuIE90aGVyd2lzZSwg
d2UgY2FuIG5vdCBoYXZlIGNvbW1vbiBjb2RlIHRvIHBhcnNlDQo+IHRoZSBEVCBhbmQgZmluZCBk
ZXZpY2VzIGF0dGFjaGVkIHRvIGEgVUFSVC4NCj4NCj4gSUY6IENoYW5jZXMgYXJlIEkgd2FzIG5v
dCBjbGVhciBlbm91Z2guIEkgd2FzIG5vdCB0YWxraW5nIGFib3V0IGNvbm5lY3RpbmcgbXVsdGlw
bGUgZGV2aWNlcyB0byBhIFVBUlQuIEkgd2FzIHRhbGtpbmcgYWJvdXQgY29ubmVjdGluZyBvbmUg
QnJvYWRjb20gQlQgZGV2aWNlIHRvIG9uZSBzZXJpYWwgcG9ydCBhbmQgYW5vdGhlciBCcm9hZGNv
bSBCVCBkZXZpY2UgdG8gYW5vdGhlciBzZXJpYWwgcG9ydCAocmFyZSBlbm91Z2ggc2V0dXApLiBJ
IGRvIHVuZGVyc3RhbmQgeW91ciBnb2FscyB0aG91Z2guIEkgd291bGQgYmUgaGFwcHkgdG8gcGFy
dGljaXBhdGUgaW4gdGhhdCBleGVyY2lzZSAoc3ViamVjdCB0byB0aGUgbWFuYWdlbWVudCBhcHBy
b3ZhbCkgb25jZSBEVCBoYXMgcHVibGlzaGVkIHRoZSBVQVJUIGRldmljZSBwYXJhbWV0ZXJzIGFu
ZCB0aGUgTGludXggYmx1ZXRvb3RoLW5leHQgaGFzIHN1cHBvcnQgZm9yIERUIGVudW1lcmF0ZWQg
ZGV2aWNlcy4gSSBkb27igJl0IHNlZSBpdCBoYXBwZW5pbmcgc29vbiB0aG91Z2guIE1hcnZlbGwg
ZXhhbXBsZSB5b3UndmUgcmVmZXJyZWQgbWUgdG8gaGFzIG5vdGhpbmcgb2YgdGhlIHNvcnQuIFdo
YXQgZG8geW91IHRoaW5rIG9mIGFsbG93aW5nIHVzIHNvbWV0aGluZyB0byBzaGlwIG5vdyB3aXRo
IGFuIHVuZGVyc3RhbmRpbmcgdGhhdCB3ZSB3b3VsZCBzdXBwb3J0IHlvdXIgVUFSVCBlbnVtZXJh
dGVkIGRldmljZXMgb25jZSB0aGV5IGFyZSBwdWJsaXNoZWQ/DQoNCk9rYXkuIFNldmVyYWwgcGVv
cGxlIHdhbnQgdG8gZGVzY3JpYmUgYSBjb25uZWN0aW9uIGJldHdlZW4gYSBob3N0IHVhcnQNCmFu
ZCBhIGRldmljZSBjb25uZWN0ZWQgdG8gdGhlIHVhcnQgKEJULCBORkMsIEdQUywgZXRjLikuIFlv
dSBhcmUgZG9pbmcNCnRoaXMgd2l0aCB5b3VyICJ0dHkiIHByb3BlcnR5LiBNeSBnb2FsIGFuZCBy
ZXF1aXJlbWVudCBpcyB0aGF0IHRoaXMNCmNvbm5lY3Rpb24gYmUgZGVzY3JpYmVkIGluIERUIGlu
IHRoZSBzYW1lIHdheSByZWdhcmRsZXNzIG9mIHRoZSBkZXZpY2UNCmF0dGFjaGVkLiBKdXN0IGxp
a2UgYWxsIEkyQyBkZXZpY2UgY29ubmVjdGlvbnMgYXJlIGRlc2NyaWJlZCBieSBiZWluZw0KY2hp
bGQgbm9kZXMgdW5kZXIgdGhlIEkyQyBob3N0IHJlZ2FyZGxlc3Mgb2YgdGhlIHR5cGUgb2YgSTJD
IGRldmljZQ0KYXR0YWNoZWQuDQoNCklGOiBBbGwgZ29vZCBwb2ludHMsIFJvYi4gSSB3aWxsIGNl
cnRhaW5seSBnZXQgcmlkIG9mIHRoZSB0dHkgcHJvcGVydHkgaWYgSSBjYW4gbWFrZSB0aGUgY2hp
bGQgZGV2aWNlIGlkZWEgd29yay4gTXkgY29tcGxpY2F0aW9uIGlzIGluIHRoZSBuZWVkIHRvIG1h
cCBzYXkgdGhlIERUIGRldmljZSBwYXJlbnQgKFVBUlQpIGludG8gdGhlIHR0eV9zdHJ1Y3QgdXNl
ZCBieSB0aGUgTGludXggQmx1ZVogcHJvdG9jb2wuIEFueSBpZGVhcyBvbiBob3cgdG8gaW1wbGVt
ZW50IHRoYXQgPyBNYW55IHRoYW5rcyENCg0KUm9iDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
next prev parent reply other threads:[~2015-06-19 20:37 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-17 21:30 [PATCH v4 0/4] Broadcom Bluetooth UART device driver Ilya Faenson
2015-06-17 21:30 ` [PATCH v4 1/4] Broadcom Bluetooth UART Device Tree bindings Ilya Faenson
2015-06-17 21:33 ` Arend van Spriel
[not found] ` <1434576658-20730-2-git-send-email-ifaenson-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2015-06-17 23:11 ` FW: " Ilya Faenson
2015-06-17 23:11 ` Ilya Faenson
[not found] ` <E0D3336E15B58B4294723AC879BA5E942634F2-Wwdb2uEOBX8N93KskqRXH71+IgudQmzARxWJa1zDYLQ@public.gmane.org>
2015-06-18 15:02 ` Rob Herring
2015-06-18 15:02 ` Rob Herring
[not found] ` <CAL_JsqK9kup3sm3qgDLqtT8ajrN1ee6zfXwOoZqoq9cXQNwE_w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-18 18:54 ` Ilya Faenson
2015-06-18 18:54 ` Ilya Faenson
[not found] ` <E0D3336E15B58B4294723AC879BA5E94263E58-Wwdb2uEOBX8N93KskqRXH71+IgudQmzARxWJa1zDYLQ@public.gmane.org>
2015-06-18 19:41 ` Rob Herring
2015-06-18 19:41 ` Rob Herring
[not found] ` <CAL_JsqJAUTjNehtr_Af93k71mdSREb9pLMoSyDTm1S42VkA2sQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-18 20:37 ` Ilya Faenson
2015-06-18 20:37 ` Ilya Faenson
[not found] ` <E0D3336E15B58B4294723AC879BA5E942640A3-Wwdb2uEOBX8N93KskqRXH71+IgudQmzARxWJa1zDYLQ@public.gmane.org>
2015-06-19 15:47 ` Rob Herring
2015-06-19 15:47 ` Rob Herring
[not found] ` <CAL_JsqJKyj8sDwG82jb_CzXEDBN8aznR7eF5yTOiWruW8o3cng-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-19 17:06 ` Arend van Spriel
2015-06-19 17:06 ` Arend van Spriel
[not found] ` <55844C1E.8020301-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2015-06-19 18:49 ` Rob Herring
2015-06-19 18:49 ` Rob Herring
[not found] ` <CAL_JsqLr7JZ9=i2XuWR0_FZDyxpDRwDS5dkSpzjKA-8V=-mpOw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2015-06-19 19:20 ` Arend van Spriel
2015-06-19 19:20 ` Arend van Spriel
[not found] ` <55846B7D.1060601-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2015-06-29 18:36 ` Arend van Spriel
2015-06-29 18:36 ` Arend van Spriel
[not found] ` <55919023.200-dY08KVG/lbpWk0Htik3J/w@public.gmane.org>
2015-07-02 18:26 ` Rob Herring
2015-07-02 18:26 ` Rob Herring
2015-06-19 20:37 ` Ilya Faenson [this message]
2015-06-19 20:37 ` Ilya Faenson
2015-06-19 19:23 ` Fabio Estevam
2015-06-19 20:40 ` Ilya Faenson
2015-06-17 21:30 ` [PATCH v4 2/4] hci_uart: line discipline enhancements Ilya Faenson
2015-06-17 21:50 ` Marcel Holtmann
2015-06-17 21:53 ` Ilya Faenson
2015-06-18 9:46 ` Frederic Danis
2015-06-18 10:17 ` Marcel Holtmann
2015-06-17 21:30 ` [PATCH v4 3/4] btbcm_uart: Broadcom UART Platform Driver Ilya Faenson
2015-06-17 21:30 ` [PATCH v4 4/4] hci_bcm: Broadcom UART protocol enhancements Ilya Faenson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=E0D3336E15B58B4294723AC879BA5E94264862@IRVEXCHMB15.corp.ad.broadcom.com \
--to=ifaenson-dy08kvg/lbpwk0htik3j/w@public.gmane.org \
--cc=arend-dY08KVG/lbpWk0Htik3J/w@public.gmane.org \
--cc=devicetree-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=linux-bluetooth-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=marcel-kz+m5ild9QBg9hUCZPvPmw@public.gmane.org \
--cc=robherring2-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.