Hi Loic, -----Original Message----- From: Loic Poulain [mailto:loic.poulain@xxxxxxxxx] Sent: Thursday, August 20, 2015 4:58 AM To: Ilya Faenson; marcel@xxxxxxxxxxxx Cc: linux-bluetooth@xxxxxxxxxxxxxxx Subject: Re: [PATCH] Bluetooth: hci_intel: Add platform driver Thanks Ilya, > Is there a patch with the DT documentation? It would be interesting to see what DT maintainers think of this approach. I don't have any documentation for now. > That allows you to run with a single device per platform only. Meanwhile, you could have something in the DT parameters identifying the UART. You would then be able to retrieve that parameter and match it against the tty in the BT protocol. Multiple devices per platform would then be supported. Actually It supports multiple chips but takes them in the registered order. But, I agree, it's not a correct way to do that. I'm not a DT expert but I think we can do this match in the same way as acpi. It just requires to make the Bluetooth entry a child of the serial port entry. for example: In dtsi you could have the usual uart description: uart1: serial@1 { compatible = "vendor,vendor-uart"; reg = <0x4806a000 0x100>; interrupts = <GIC_SPI 72 IRQ_TYPE_LEVEL_HIGH>; clock-frequency = <48000000>; ... }; And in the dts overlay, just add the device as a child node: uart1: serial@1 { bt-vendor { compatible = "vendor,bt-vendor"; reset-gpio = <&pmx_gpio 77 0 >; interrupts = < 2 VENDOR_IRQ_TYPE_EDGE_FALLING >; ... } } I think it's a good way to link the tty with the pdev and there is no specific label to add and document. What do you think about this? I'm not specially against adding a parameter (vendor,tty = "ttys1"). But it means that you need to be sure that your serial will be always named "ttys1", if someone remove/disable/add a serial port in a dts/dtsi, it can shift the tty number assigned by the driver. IF: All good ideas, Loic. I initially wanted BT DT configuration to be "like ACPI" too. The response from the DT maintainer was "DT's not ACPI". He essentially wanted us to describe the whole combo chip as a device with BT being one of the sub-devices. The point was that BT/WiFi/GPS/NFC/FM/whatever are dependent on each other and on some properties of the whole chip, say on power or clock. There is some truth to that but I believe the BT relationship to the UART is of more relevance to its driver than to the rest of the overall chip. In any case, we were not able to find common ground (no response to my last couple of messages) resulting in a customer not using bluetooth-next for that BT device integration. I guess DT has its own interests and seems to care little about BlueZ. I hope therefore that the second similar request from the major hardware vendor (you guys) will make DT more cooperative. All hardware vendors will then be able to benefit from whatever scheme gets accepted. To make a long story short, I encourage you to start including DT in your patches. :-) Regards, Loic -- Intel Open Source Technology Center http://oss.intel.com/ -- 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
