Hi Sebastian,
>> diff --git a/Documentation/devicetree/bindings/serial/slave-reg.txt
>> b/Documentation/devicetree/bindings/serial/slave-reg.txt
>> new file mode 100644
>> index 000000000000..7896bce8dfe4
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/serial/slave-reg.txt
>> @@ -0,0 +1,18 @@
>> +Regulator powered UART-attached device
>> +
>> +Required properties:
>> +- compatible: "tty,regulator"
>> +- vdd-supply: regulator to power the device
>> +
>> +
>> +This is listed as a child node of a UART. When the
>> +UART is opened, the device is powered.
>> +
>> +Example:
>> +
>> +&uart1 {
>> + bluetooth {
>> + compatible = "tty,regulator";
>> + vdd-supply = <&vaux4>;
>> + };
>> +};
>
> NACK. The compatible value should describe the connected device. You
> did not connect a regulator, but a bluetooth chip! DT should look
> like this:
>
> &uart1 {
> bluetooth {
> compatible = "vendor,bluetooth-chip";
> vdd-supply = <&vaux4>;
> };
> };
>
> I think it would be ok to use your generic driver to handle the
> specific compatible value, though.
>
> Having the proper compatible value means, that there can be a more
> specific driver later, that other operating systems can expose the
> device as some kind of /dev/bluetooth instead of /dev/ttyXY, that
> userspace is able to know there is a bluetooth device connected to
> /dev/ttyXY by parsing the DT and results in easier-to-understand
> DTS.
I think that is up to udev to be able to make this a nice device node. However
the device node name is pretty much irrelevant. What you want is enough meta
data to tell that there is Bluetooth chip behind this TTY. From a Bluetooth
stack perspective only hciattach needs to be run to get the N_HCI line
discipline up and running for that chip.
However what would be interesting for hciattach would be a possibility to
expose the Bluetooth manufacturer. Since the init routine is different for each
manufacturer. So if that could be encoded in the DT, then that would be
certainly helpful.
Regards
Marcel
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
