> So you mean if I do "hciconfig hci0 down", then the uart-bus should
> "down" the tty and only on "hciconfig hci0 up" it should "up" the
> tty? I would expect a uart-bus slave-device takes control of the
> device ("up" it) on probe. It's hardwired anyway.
Today you can switch stacks at runtime, you can switch between the kernel
stack and debug tools at runtime. Breaking that is a regression.
> Also what should happen if old userspace use hciattach while
> uart-bus slave-device doesn't have control over it? Do you
You would either use the old hciattach in which case you wouldn't be able
to manage it via a new API while attached, or the new API in which case
you wouldn't be able to manage it via the old interface while it was
being used directly.
> Or do you suggest to register hci1 and one cannot use hci0? I guess
> this breaks even more devices, as the device number changes.
Device numbers are dynamic anyway. Plug a USB adapter in and if it beats
your onboard adapter to registration then the order changes.
> So yes, from your point of view there is a regression, just because
> it's working automatically. So let's just not convert existing boards
> with working hciattach based bluetooth devices. New devices can use
>From a distribution point of view that would be a nightmare.
> the uart-bus, as it's not a regression for them and Nokia N series
> can also do it, since they have no working bluetooth at all at the
> moment.
The Nokia N series is a weird corner case.
> > In many cases you'll also still need the tty interface to do
> > things like firmware upgrades.
>
> I would expect the uart-slave driver to know how to do firmware
> updates. Actually most bluetooth chips are initialized by uploading
> a firmware to them.
Usually no - you don't want a ton of kernel code for flashing adapters
when they have built in firmware (similar issue for 3G modems)
> And there are definitely uart drivers not caring about having a tty
> device. Nokia's vendor driver for their bluetooth protocol contains
> a custom omap-serial driver combined with the actual bluetooth
> driver. There is nothing related to the tty framework. I think the
> same would work for the other hardwired bluetooth chips perfectly
> fine.
That means having two different omap serial drivers to maintain which is
not ideal.
To me there are four different things
1. bluetooth devices "just work". That can be user space (eg it seems to
just work on my Fedora boxes and bluetooth enumeration is being done via
user space, or may be via kernel enumeration, or a mix. PPP is an
existing example of this - serial port PPP is an ldisc but ports that are
not UART like speak directly to the PPP layer as network adapters.
2. Sideband controls and power management, where we need to give the
tty_port a child device and power it up/down properly and have the
tty_port hooks to do so based upon the ldisc protocol state machine when
talking stuff like NMEA or HCI.
3. The special case UART power saving features/hacks like GPIO snooping,
again with the right hooks
4. Whether it's useful to be able to create a tty device in kernel and
attach that to stuff with no userspace involved.
All are independent.
Alan
--
To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
