Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi all, > Am 12.01.2019 um 12:16 schrieb Jon Nettleton : > > On Fri, Jan 4, 2019 at 8:57 PM Andreas Kemnade wrote: >> >> Hi Marcel, >> >> On Fri, 4 Jan 2019 10:07:34 +0100 >> Marcel Holtmann 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==169671==%5Bv5== 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Fri, Jan 4, 2019 at 8:57 PM Andreas Kemnade wrote: > > Hi Marcel, > > On Fri, 4 Jan 2019 10:07:34 +0100 > Marcel Holtmann 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi Marcel, On Fri, 4 Jan 2019 10:07:34 +0100 Marcel Holtmann 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 pgprFvwfDCiNm.pgp Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi Marcel, On Fri, 16 Nov 2018 20:58:24 +0100 Marcel Holtmann 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 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 pgp39MeZcowR2.pgp Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi Marcel, On Wed, 14 Nov 2018 08:51:17 +0100 Marcel Holtmann 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 pgpngjN3jT8uQ.pgp Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi Marcel, On Wed, 14 Nov 2018 08:51:17 +0100 Marcel Holtmann 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 pgpngjN3jT8uQ.pgp Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Wed, 14 Nov 2018 08:51:17 +0100
Marcel Holtmann wrote:
> Hi Andreas,
>
> > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> > On Sun, 11 Nov 2018 03:46:48 +0100
> > Sebastian Reichel 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
> >>> ---
> >>
> >> 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", "";
> >>>
> > 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
pgpQavF8pjyKK.pgp
Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Wed, 14 Nov 2018 08:51:17 +0100
Marcel Holtmann wrote:
> Hi Andreas,
>
> > Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> > On Sun, 11 Nov 2018 03:46:48 +0100
> > Sebastian Reichel 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
> >>> ---
> >>
> >> 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", "";
> >>>
> > 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
pgpQavF8pjyKK.pgp
Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi Andreas,
> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel 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
>>> ---
>>
>> 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", "";
>>>
> 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
Hi Andreas,
> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel 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
>>> ---
>>
>> 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", "";
>>>
> 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Mon, 12 Nov 2018 18:17:38 -0600
Rob Herring wrote:
> On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
> 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 :
> > > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > > Sebastian Reichel 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
> > > >>> ---
> > > >>
> > > >> 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", "";
> >
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
pgpdHRXoCT27d.pgp
Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Mon, 12 Nov 2018 18:17:38 -0600
Rob Herring wrote:
> On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
> 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 :
> > > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > > Sebastian Reichel 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
> > > >>> ---
> > > >>
> > > >> 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", "";
> >
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
pgpdHRXoCT27d.pgp
Description: OpenPGP digital signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
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 :
> > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > Sebastian Reichel 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
> > >>> ---
> > >>
> > >> 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", "";
>
> 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
On Mon, Nov 12, 2018 at 4:27 PM Sebastian Reichel
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 :
> > > On Sun, 11 Nov 2018 03:46:48 +0100
> > > Sebastian Reichel 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
> > >>> ---
> > >>
> > >> 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", "";
>
> 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
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 :
> > On Sun, 11 Nov 2018 03:46:48 +0100
> > Sebastian Reichel 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
> >>> ---
> >>
> >> 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", "";
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
signature.asc
Description: PGP signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
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 :
> > On Sun, 11 Nov 2018 03:46:48 +0100
> > Sebastian Reichel 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
> >>> ---
> >>
> >> 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", "";
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
signature.asc
Description: PGP signature
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
>
> Hi,
>
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel 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
>>> ---
>>
>> 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
Re: [Letux-kernel] [PATCH RFC] bluetooth: add uart h4 devices via serdev/devicetree
> Am 12.11.2018 um 21:59 schrieb Andreas Kemnade :
>
> Hi,
>
> On Sun, 11 Nov 2018 03:46:48 +0100
> Sebastian Reichel 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
>>> ---
>>
>> 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
