This is a first try to be able to use h4 devices specified in
the devicetree, so you do not need to call hciattach and
it can be automatically probed.
Of course, proper devicetree bindings documentation is
missing. And also you would extend that by regulator/
enable gpio settings.
But before proceeding further it should be checked if the
general way of doing things is right.
Signed-off-by: Andreas Kemnade <[email protected]>
---
drivers/bluetooth/hci_h4.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++
1 file changed, 78 insertions(+)
diff --git a/drivers/bluetooth/hci_h4.c b/drivers/bluetooth/hci_h4.c
index fb97a3bf069b..8df0611d976c 100644
--- a/drivers/bluetooth/hci_h4.c
+++ b/drivers/bluetooth/hci_h4.c
@@ -39,6 +39,8 @@
#include <linux/string.h>
#include <linux/signal.h>
#include <linux/ioctl.h>
+#include <linux/of.h>
+#include <linux/serdev.h>
#include <linux/skbuff.h>
#include <asm/unaligned.h>
@@ -47,6 +49,11 @@
#include "hci_uart.h"
+struct h4_device {
+ struct hci_uart hu;
+ bool flow;
+};
+
struct h4_struct {
struct sk_buff *rx_skb;
struct sk_buff_head txq;
@@ -146,9 +153,76 @@ static struct sk_buff *h4_dequeue(struct hci_uart *hu)
return skb_dequeue(&h4->txq);
}
+#if IS_ENABLED(CONFIG_SERIAL_DEV_BUS)
+static int h4_setup(struct hci_uart *hu)
+{
+ struct h4_device *h4dev;
+ struct serdev_device *serdev = hu->serdev;
+
+ if (!serdev)
+ return 0;
+
+ h4dev = serdev_device_get_drvdata(serdev);
+
+ serdev_device_set_flow_control(serdev, h4dev->flow);
+
+ return 0;
+}
+
+static const struct hci_uart_proto h4p;
+
+static int hci_h4_probe(struct serdev_device *serdev)
+{
+ struct hci_uart *hu;
+ struct h4_device *h4dev;
+ u32 speed = 3000000;
+
+ h4dev = devm_kzalloc(&serdev->dev, sizeof(struct h4_device),
+ GFP_KERNEL);
+ if (!h4dev)
+ return -ENOMEM;
+ hu = &h4dev->hu;
+
+ serdev_device_set_drvdata(serdev, h4dev);
+ hu->serdev = serdev;
+
+ h4dev->flow = of_property_read_bool(serdev->dev.of_node, "flow");
+
+ of_property_read_u32(serdev->dev.of_node, "speed", &speed);
+ hci_uart_set_speeds(hu, speed, speed);
+
+ return hci_uart_register_device(hu, &h4p);
+}
+
+static void hci_h4_remove(struct serdev_device *serdev)
+{
+ struct h4_device *h4dev = serdev_device_get_drvdata(serdev);
+
+ hci_uart_unregister_device(&h4dev->hu);
+}
+
+static const struct of_device_id hci_h4_of_match[] = {
+ { .compatible = "wi2wi,w2cbw003-bluetooth"},
+ {},
+};
+MODULE_DEVICE_TABLE(of, hci_h4_of_match);
+
+static struct serdev_device_driver hci_h4_drv = {
+ .driver = {
+ .name = "hci-h4",
+ .of_match_table = of_match_ptr(hci_h4_of_match),
+ },
+ .probe = hci_h4_probe,
+ .remove = hci_h4_remove
+};
+#else
+#define h4_setup NULL
+#endif
+
static const struct hci_uart_proto h4p = {
.id = HCI_UART_H4,
.name = "H4",
+ .setup = h4_setup,
.open = h4_open,
.close = h4_close,
.recv = h4_recv,
@@ -159,11 +233,15 @@ static const struct hci_uart_proto h4p = {
int __init h4_init(void)
{
+ serdev_device_driver_register(&hci_h4_drv);
+
return hci_uart_register_proto(&h4p);
}
int __exit h4_deinit(void)
{
+ serdev_device_driver_unregister(&hci_h4_drv);
+
return hci_uart_unregister_proto(&h4p);
}
--
2.11.0
Hi,
On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> This is a first try to be able to use h4 devices specified in
> the devicetree, so you do not need to call hciattach and
> it can be automatically probed.
>
> Of course, proper devicetree bindings documentation is
> missing. And also you would extend that by regulator/
> enable gpio settings.
>
> But before proceeding further it should be checked if the
> general way of doing things is right.
>
> Signed-off-by: Andreas Kemnade <[email protected]>
> ---
Patch looks good to me, just one note
> drivers/bluetooth/hci_h4.c | 78 ++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 78 insertions(+)
>
[...]
> + return hci_uart_register_device(hu, &h4p);
> +}
> +
> +static void hci_h4_remove(struct serdev_device *serdev)
> +{
> + struct h4_device *h4dev = serdev_device_get_drvdata(serdev);
> +
> + hci_uart_unregister_device(&h4dev->hu);
> +}
I suggest to add a patch introducing
devm_hci_uart_register_device()
All existing users of hci_uart_register_device() could use it
(your driver, hci_bcm, hci_h5, hci_ll, hci_nokia and hci_qca)
and all drivers but hci_qca can drop their remove function.
-- Sebastian
Hi,
On Sun, 11 Nov 2018 03:46:48 +0100
Sebastian Reichel <[email protected]> wrote:
> Hi,
>
> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> > This is a first try to be able to use h4 devices specified in
> > the devicetree, so you do not need to call hciattach and
> > it can be automatically probed.
> >
> > Of course, proper devicetree bindings documentation is
> > missing. And also you would extend that by regulator/
> > enable gpio settings.
> >
> > But before proceeding further it should be checked if the
> > general way of doing things is right.
> >
> > Signed-off-by: Andreas Kemnade <[email protected]>
> > ---
>
> Patch looks good to me, just one note
>
I found one thing myself:
Shouldn't we have a generic compatible string like "generic-h4".
ehci-platform.c has for example:
{ .compatible = "generic-ehci", },
Regards,
Andreas
> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <[email protected]>:
>
> Hi,
>
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel <[email protected]> wrote:
>
>> Hi,
>>
>> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
>>> This is a first try to be able to use h4 devices specified in
>>> the devicetree, so you do not need to call hciattach and
>>> it can be automatically probed.
>>>
>>> Of course, proper devicetree bindings documentation is
>>> missing. And also you would extend that by regulator/
>>> enable gpio settings.
>>>
>>> But before proceeding further it should be checked if the
>>> general way of doing things is right.
>>>
>>> Signed-off-by: Andreas Kemnade <[email protected]>
>>> ---
>>
>> Patch looks good to me, just one note
>>
> I found one thing myself:
> Shouldn't we have a generic compatible string like "generic-h4".
> ehci-platform.c has for example:
> { .compatible = "generic-ehci", },
There might be differences in h4 compatible devices (e.g. default
baud rate) so that I would not bet there a "generic-h4" suffices
in the long run.
And, shouldn't there be a vendor prefix anyways?
I.e. something like "bluetooth,h4"? Because it seems to be defined in
https://www.bluetooth.org/docman/handlers/DownloadDoc.ashx?doc_id=41266
On the other hand, with hci-ll protocol the compatible strings are chip variants.
Well, this seems to be required to decide which firmware to download.
So it boils down to if DT compatibility should be compatible to generic
functions or specific chips? AFAI see this is more or less random and
there seems to be no general rule.
Just some thoughts but no strong preference.
BR,
Nikolaus
Hi,
On Mon, Nov 12, 2018 at 10:19:02PM +0100, H. Nikolaus Schaller wrote:
> > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <[email protected]>:
> > On Sun, 11 Nov 2018 03:46:48 +0100
> > Sebastian Reichel <[email protected]> wrote:
> >> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> >>> This is a first try to be able to use h4 devices specified in
> >>> the devicetree, so you do not need to call hciattach and
> >>> it can be automatically probed.
> >>>
> >>> Of course, proper devicetree bindings documentation is
> >>> missing. And also you would extend that by regulator/
> >>> enable gpio settings.
> >>>
> >>> But before proceeding further it should be checked if the
> >>> general way of doing things is right.
> >>>
> >>> Signed-off-by: Andreas Kemnade <[email protected]>
> >>> ---
> >>
> >> Patch looks good to me, just one note
> >>
> > I found one thing myself:
> > Shouldn't we have a generic compatible string like "generic-h4".
> > ehci-platform.c has for example:
> > { .compatible = "generic-ehci", },
>
> There might be differences in h4 compatible devices (e.g. default
> baud rate) so that I would not bet there a "generic-h4" suffices
> in the long run.
My suggestion is to use this in DT:
compatible = "wi2wi,w2cbw003-bluetooth", "<something generic>";
The driver can start with supporting just the generic compatible
string. If somebody finds some incompatible differences, the driver
can add a custom handler for the wi2wi chip without breaking DT
ABI.
-- Sebastian
On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
<[email protected]> wrote:
>
> Hi,
>
> On Mon, Nov 12, 2018 at 10:19:02PM +0100, H. Nikolaus Schaller wrote:
> > > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <[email protected]>:
> > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > Sebastian Reichel <[email protected]> wrote:
> > >> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> > >>> This is a first try to be able to use h4 devices specified in
> > >>> the devicetree, so you do not need to call hciattach and
> > >>> it can be automatically probed.
> > >>>
> > >>> Of course, proper devicetree bindings documentation is
> > >>> missing. And also you would extend that by regulator/
> > >>> enable gpio settings.
> > >>>
> > >>> But before proceeding further it should be checked if the
> > >>> general way of doing things is right.
> > >>>
> > >>> Signed-off-by: Andreas Kemnade <[email protected]>
> > >>> ---
> > >>
> > >> Patch looks good to me, just one note
> > >>
> > > I found one thing myself:
> > > Shouldn't we have a generic compatible string like "generic-h4".
> > > ehci-platform.c has for example:
> > > { .compatible = "generic-ehci", },
> >
> > There might be differences in h4 compatible devices (e.g. default
> > baud rate) so that I would not bet there a "generic-h4" suffices
> > in the long run.
It will not because that doesn't define clocks, resets, gpios,
supplies, etc. and the interactions of all those.
> My suggestion is to use this in DT:
>
> compatible = "wi2wi,w2cbw003-bluetooth", "<something generic>";
>
> The driver can start with supporting just the generic compatible
> string. If somebody finds some incompatible differences, the driver
> can add a custom handler for the wi2wi chip without breaking DT
> ABI.
Any idea how many H4 devices there are? Somehow I doubt there are that
many to be unmanageable.
Rob
On Mon, 12 Nov 2018 18:17:38 -0600
Rob Herring <[email protected]> wrote:
> On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
> <[email protected]> wrote:
> >
> > Hi,
> >
> > On Mon, Nov 12, 2018 at 10:19:02PM +0100, H. Nikolaus Schaller wrote:
> > > > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <[email protected]>:
> > > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > > Sebastian Reichel <[email protected]> wrote:
> > > >> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> > > >>> This is a first try to be able to use h4 devices specified in
> > > >>> the devicetree, so you do not need to call hciattach and
> > > >>> it can be automatically probed.
> > > >>>
> > > >>> Of course, proper devicetree bindings documentation is
> > > >>> missing. And also you would extend that by regulator/
> > > >>> enable gpio settings.
> > > >>>
> > > >>> But before proceeding further it should be checked if the
> > > >>> general way of doing things is right.
> > > >>>
> > > >>> Signed-off-by: Andreas Kemnade <[email protected]>
> > > >>> ---
> > > >>
> > > >> Patch looks good to me, just one note
> > > >>
> > > > I found one thing myself:
> > > > Shouldn't we have a generic compatible string like "generic-h4".
> > > > ehci-platform.c has for example:
> > > > { .compatible = "generic-ehci", },
> > >
> > > There might be differences in h4 compatible devices (e.g. default
> > > baud rate) so that I would not bet there a "generic-h4" suffices
> > > in the long run.
>
> It will not because that doesn't define clocks, resets, gpios,
> supplies, etc. and the interactions of all those.
>
well, we need a simple supply being on when the device is on.
Nothing more.
> > My suggestion is to use this in DT:
> >
> > compatible = "wi2wi,w2cbw003-bluetooth", "<something generic>";
> >
That would be my slight preference here.
> > The driver can start with supporting just the generic compatible
> > string. If somebody finds some incompatible differences, the driver
> > can add a custom handler for the wi2wi chip without breaking DT
> > ABI.
>
> Any idea how many H4 devices there are? Somehow I doubt there are that
> many to be unmanageable.
>
Well, many devices are h4 devices with some more or less important
vendor-specific commands. Well, "hciattach any" uses simple h4 protocol.
those firmware download commands and they have their own drivers.
Most devices I had used bluetooth uart from the command line with, were
simple enough. The other question is whether those devices will run a
modern kernel.
No strong opinion here.
Regards,
Andreas
Hi Andreas,
>>>>> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <[email protected]>:
>>>>> On Sun, 11 Nov 2018 03:46:48 +0100
>>>>> Sebastian Reichel <[email protected]> wrote:
>>>>>> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
>>>>>>> This is a first try to be able to use h4 devices specified in
>>>>>>> the devicetree, so you do not need to call hciattach and
>>>>>>> it can be automatically probed.
>>>>>>>
>>>>>>> Of course, proper devicetree bindings documentation is
>>>>>>> missing. And also you would extend that by regulator/
>>>>>>> enable gpio settings.
>>>>>>>
>>>>>>> But before proceeding further it should be checked if the
>>>>>>> general way of doing things is right.
>>>>>>>
>>>>>>> Signed-off-by: Andreas Kemnade <[email protected]>
>>>>>>> ---
>>>>>>
>>>>>> Patch looks good to me, just one note
>>>>>>
>>>>> I found one thing myself:
>>>>> Shouldn't we have a generic compatible string like "generic-h4".
>>>>> ehci-platform.c has for example:
>>>>> { .compatible = "generic-ehci", },
>>>>
>>>> There might be differences in h4 compatible devices (e.g. default
>>>> baud rate) so that I would not bet there a "generic-h4" suffices
>>>> in the long run.
>>
>> It will not because that doesn't define clocks, resets, gpios,
>> supplies, etc. and the interactions of all those.
>>
> well, we need a simple supply being on when the device is on.
> Nothing more.
>
>>> My suggestion is to use this in DT:
>>>
>>> compatible = "wi2wi,w2cbw003-bluetooth", "<something generic>";
>>>
> That would be my slight preference here.
>
>>> The driver can start with supporting just the generic compatible
>>> string. If somebody finds some incompatible differences, the driver
>>> can add a custom handler for the wi2wi chip without breaking DT
>>> ABI.
>>
>> Any idea how many H4 devices there are? Somehow I doubt there are that
>> many to be unmanageable.
>>
> Well, many devices are h4 devices with some more or less important
> vendor-specific commands. Well, "hciattach any" uses simple h4 protocol.
>
> those firmware download commands and they have their own drivers.
> Most devices I had used bluetooth uart from the command line with, were
> simple enough. The other question is whether those devices will run a
> modern kernel.
>
> No strong opinion here.
doing the firmware load from user space via some magic tool is no longer going to work smoothly. It will be actually almost impossible with serdev. However I did post btuart.c driver which is pretty much just plain H:4. You would still somehow define the default baudraute since just picking 115200 is not always going to work.
Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
Regards
Marcel
On Wed, 14 Nov 2018 08:51:17 +0100
Marcel Holtmann <[email protected]> wrote:
> Hi Andreas,
>
> >>>>> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade <[email protected]>:
> >>>>> On Sun, 11 Nov 2018 03:46:48 +0100
> >>>>> Sebastian Reichel <[email protected]> wrote:
> >>>>>> On Sun, Nov 11, 2018 at 12:20:34AM +0100, Andreas Kemnade wrote:
> >>>>>>> This is a first try to be able to use h4 devices specified in
> >>>>>>> the devicetree, so you do not need to call hciattach and
> >>>>>>> it can be automatically probed.
> >>>>>>>
> >>>>>>> Of course, proper devicetree bindings documentation is
> >>>>>>> missing. And also you would extend that by regulator/
> >>>>>>> enable gpio settings.
> >>>>>>>
> >>>>>>> But before proceeding further it should be checked if the
> >>>>>>> general way of doing things is right.
> >>>>>>>
> >>>>>>> Signed-off-by: Andreas Kemnade <[email protected]>
> >>>>>>> ---
> >>>>>>
> >>>>>> Patch looks good to me, just one note
> >>>>>>
> >>>>> I found one thing myself:
> >>>>> Shouldn't we have a generic compatible string like "generic-h4".
> >>>>> ehci-platform.c has for example:
> >>>>> { .compatible = "generic-ehci", },
> >>>>
> >>>> There might be differences in h4 compatible devices (e.g. default
> >>>> baud rate) so that I would not bet there a "generic-h4" suffices
> >>>> in the long run.
> >>
> >> It will not because that doesn't define clocks, resets, gpios,
> >> supplies, etc. and the interactions of all those.
> >>
> > well, we need a simple supply being on when the device is on.
> > Nothing more.
> >
> >>> My suggestion is to use this in DT:
> >>>
> >>> compatible = "wi2wi,w2cbw003-bluetooth", "<something generic>";
> >>>
> > That would be my slight preference here.
> >
> >>> The driver can start with supporting just the generic compatible
> >>> string. If somebody finds some incompatible differences, the driver
> >>> can add a custom handler for the wi2wi chip without breaking DT
> >>> ABI.
> >>
> >> Any idea how many H4 devices there are? Somehow I doubt there are that
> >> many to be unmanageable.
> >>
> > Well, many devices are h4 devices with some more or less important
> > vendor-specific commands. Well, "hciattach any" uses simple h4 protocol.
> >
> > those firmware download commands and they have their own drivers.
> > Most devices I had used bluetooth uart from the command line with, were
> > simple enough. The other question is whether those devices will run a
> > modern kernel.
> >
> > No strong opinion here.
>
> doing the firmware load from user space via some magic tool is no longer going to work smoothly. It will be actually almost impossible with serdev. However I did post btuart.c driver which is pretty much just plain H:4. You would still somehow define the default baudraute since just picking 115200 is not always going to work.
>
Just to avoid some misunderstandings here. With this RFC patch I have only
devices in mind where we do not know any vendor specific commands and
do not need to do any firmware download.
> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
>
Seems to be a good idea. So in the end I should not continue
that rtc patch?
And that thing has than a devicetree string of
"h4-generic" or a list of generic h4 devices?
Regards,
Andreas
Hi Marcel,
On Wed, 14 Nov 2018 08:51:17 +0100
Marcel Holtmann <[email protected]> wrote:
[...[
> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
>
Do you mean this?
https://patchwork.kernel.org/patch/10490651/
Regards,
Andreas
Hi Andreas,
>> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
>>
> Do you mean this?
> https://patchwork.kernel.org/patch/10490651/
yes, that one.
Regards
Marcel
Hi Marcel,
On Fri, 16 Nov 2018 20:58:24 +0100
Marcel Holtmann <[email protected]> wrote:
> Hi Andreas,
>
> >> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
> >>
> > Do you mean this?
> > https://patchwork.kernel.org/patch/10490651/
>
> yes, that one.
>
Hmm, there seemed to be nothing in the pull requests regarding btuart.
Did you change plans?
commit 29d3c047b7038d7efce4f279e4d4165d69f6ccb9
Merge: 5a862f86b8e8 1629db9c7534
Author: David S. Miller <[email protected]>
Date: Wed Dec 19 08:41:45 2018 -0800
Merge branch 'for-upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next
Johan Hedberg says:
====================
pull request: bluetooth-next 2018-12-19
Here's the main bluetooth-next pull request for 4.21:
- Multiple fixes & improvements for Broadcom-based controllers
- New USB ID for an Intel controller
- Support for new Broadcom controller variants
- Use DEFINE_SHOW_ATTRIBUTE to simplify debugfs code
- Eliminate confusing "last event is not cmd complete" warning message
- Added vendor suspend/resume support for H:5 (3-Wire UART) controllers
- Various other smaller improvements & fixes
Please let me know if there are any issues pulling. Thanks.
Regards,
Andreas
Hi Andreas,
>>>> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
>>>>
>>> Do you mean this?
>>> https://patchwork.kernel.org/patch/10490651/
>>
>> yes, that one.
>>
> Hmm, there seemed to be nothing in the pull requests regarding btuart.
> Did you change plans?
because I only submitted it as RFC. We can easily merge that one upstream since it is rather trivial. The main problem is how you want to do the device matching. Do you have a DT entry for your really simple devices?
Regards
Marcel
Hi Marcel,
On Fri, 4 Jan 2019 10:07:34 +0100
Marcel Holtmann <[email protected]> wrote:
> Hi Andreas,
>
> >>>> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
> >>>>
> >>> Do you mean this?
> >>> https://patchwork.kernel.org/patch/10490651/
> >>
> >> yes, that one.
> >>
> > Hmm, there seemed to be nothing in the pull requests regarding btuart.
> > Did you change plans?
>
> because I only submitted it as RFC. We can easily merge that one upstream since it is rather trivial. The main problem is how you want to do the device matching. Do you have a DT entry for your really simple devices?
>
Hmm, in that link it is non-rfc. So someone picked you rfc patch up and
submitted it?
You might see what we are already doing here:
http://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=arch/arm/boot/dts/omap3-gta04.dtsi;h=4d2bac4293938de4a15a59979616909cf8842524;hp=bfced960d63ec40cf9db4901374b331737a9a168;hb=f78bf51754e35010de40518b9a8a148d0269bbc8;hpb=b6805813a9ab5b0d66b44cc54a0059eca4dd0a98
We are using compatible = "wi2wi,w2cbw003-bluetooth"
But I think we should also add a generic device string like
bluetooth,h4
So if people dig out older hardware, they can just add that to their
device trees and have bluetooth
The full patchset we are currently using is here:
http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/bluetooth-h4-serdev
Regards,
Andreas
On Fri, Jan 4, 2019 at 8:57 PM Andreas Kemnade <[email protected]> wrote:
>
> Hi Marcel,
>
> On Fri, 4 Jan 2019 10:07:34 +0100
> Marcel Holtmann <[email protected]> wrote:
>
> > Hi Andreas,
> >
> > >>>> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
> > >>>>
> > >>> Do you mean this?
> > >>> https://patchwork.kernel.org/patch/10490651/
> > >>
> > >> yes, that one.
> > >>
> > > Hmm, there seemed to be nothing in the pull requests regarding btuart.
> > > Did you change plans?
> >
> > because I only submitted it as RFC. We can easily merge that one upstream since it is rather trivial. The main problem is how you want to do the device matching. Do you have a DT entry for your really simple devices?
> >
> Hmm, in that link it is non-rfc. So someone picked you rfc patch up and
> submitted it?
>
> You might see what we are already doing here:
> http://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=arch/arm/boot/dts/omap3-gta04.dtsi;h=4d2bac4293938de4a15a59979616909cf8842524;hp=bfced960d63ec40cf9db4901374b331737a9a168;hb=f78bf51754e35010de40518b9a8a148d0269bbc8;hpb=b6805813a9ab5b0d66b44cc54a0059eca4dd0a98
>
> We are using compatible = "wi2wi,w2cbw003-bluetooth"
>
> But I think we should also add a generic device string like
> bluetooth,h4
> So if people dig out older hardware, they can just add that to their
> device trees and have bluetooth
>
> The full patchset we are currently using is here:
> http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/bluetooth-h4-serdev
>
> Regards,
> Andreas
Good timing for this thread. I have just integrated the mynewt blehci
firmware for the nina-b1 chip integrated onto our SOM. This is
exactly the functionality I need in the kernel to make the
initialization seamless. A generic device string is exactly what
would be needed for most devices that are running in this
configuration. We may also want to have a generic reset_gpio handler.
-Jon
Hi all,
> Am 12.01.2019 um 12:16 schrieb Jon Nettleton <[email protected]>:
>
> On Fri, Jan 4, 2019 at 8:57 PM Andreas Kemnade <[email protected]> wrote:
>>
>> Hi Marcel,
>>
>> On Fri, 4 Jan 2019 10:07:34 +0100
>> Marcel Holtmann <[email protected]> wrote:
>>
>>> Hi Andreas,
>>>
>>>>>>> Btw. I see nothing standing in the way of merging btuart.c driver and then go from there. Either I dig this out and submit or someone else does.
>>>>>>>
>>>>>> Do you mean this?
>>>>>> https://patchwork.kernel.org/patch/10490651/
>>>>>
>>>>> yes, that one.
>>>>>
>>>> Hmm, there seemed to be nothing in the pull requests regarding btuart.
>>>> Did you change plans?
>>>
>>> because I only submitted it as RFC. We can easily merge that one upstream since it is rather trivial. The main problem is how you want to do the device matching. Do you have a DT entry for your really simple devices?
>>>
>> Hmm, in that link it is non-rfc. So someone picked you rfc patch up and
>> submitted it?
I have researched a little the patchwork entry and it makes me think that Sean did post it as part of a series for MediaTek Bluetooth drivers to the mediatek mailing list (which is why we can find it in patchwork):
https://patchwork.kernel.org/project/linux-mediatek/list/?series=&submitter=169671&state=&q=%5Bv5&archive=&delegate=
It wasn't discussed there and some other patches of the series have been merged to other trees (e.g. for serdev core).
So I assume Sean is also waiting to get this patch upstream.
>> You might see what we are already doing here:
>> http://git.goldelico.com/?p=letux-kernel.git;a=blobdiff;f=arch/arm/boot/dts/omap3-gta04.dtsi;h=4d2bac4293938de4a15a59979616909cf8842524;hp=bfced960d63ec40cf9db4901374b331737a9a168;hb=f78bf51754e35010de40518b9a8a148d0269bbc8;hpb=b6805813a9ab5b0d66b44cc54a0059eca4dd0a98
>>
>> We are using compatible = "wi2wi,w2cbw003-bluetooth"
>>
>> But I think we should also add a generic device string like
>> bluetooth,h4
>> So if people dig out older hardware, they can just add that to their
>> device trees and have bluetooth
>>
>> The full patchset we are currently using is here:
>> http://git.goldelico.com/?p=letux-kernel.git;a=shortlog;h=refs/heads/letux/bluetooth-h4-serdev
>>
>> Regards,
>> Andreas
>
> Good timing for this thread. I have just integrated the mynewt blehci
> firmware for the nina-b1 chip integrated onto our SOM. This is
> exactly the functionality I need in the kernel to make the
> initialization seamless. A generic device string is exactly what
> would be needed for most devices that are running in this
> configuration. We may also want to have a generic reset_gpio handler.
>
> -Jon
BR,
Nikolaus