Hi Ilya, >>> A platform device can be used to provide some specific resources in >>> order to manage the controller. In this first patch we retrieve the >>> reset gpio which is used to power on/off the controller. >>> >>> The main issue is to match the current tty with the correct pdev. >>> In case of ACPI, we can easily find the right tty/pdev pair because >>> they are both child of the same UART port. >>> >>> If controller is powered-on from the driver, we need to wait for a >>> HCI boot event before being able to send any command. >>> >>> Signed-off-by: Loic Poulain <loic.poulain@xxxxxxxxx> >>> Signed-off-by: Marcel Holtmann <marcel@xxxxxxxxxxxx> >>> --- >>> drivers/bluetooth/hci_intel.c | 203 +++++++++++++++++++++++++++++++++++++++--- >>> 1 file changed, 190 insertions(+), 13 deletions(-) >> >> ACK, It Works on my hardware. > > okay then, this patch has been applied to bluetooth-next now. > > IF: Just out of curiosity... How come you've accepted the Intel platform device implementation yourself while you've previously referred the similar Broadcom implementation to the Device Tree folks? these are ACPI devices where we have a clear tree of parent devices. I accepted also the Broadcom version for ACPI. Within ACPI the relationship between TTY and its GPIO etc. is expressed. That is the part that is missing within DT. And the DT folks should be signing off on that. In that case DT is defining the standard on how to express these relations. For ACPI based devices this is already expressed in shipping devices. Regards Marcel -- 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
