On Mon, Apr 14, 2014 at 01:46:12PM +0200, Robert Baldyga wrote:
That's quite some CC list you've got there, and the mail seems a bit
corrupted too (it confused my MUA).
> This patch adds extcon devicetree bindings. Documentation describes in general
> client and provider bindings, and contains detailed desctiprion of bindings
> for each extcon provider.
>
> Signed-off-by: Robert Baldyga <r.baldyga@xxxxxxxxxxx>
> ---
> .../devicetree/bindings/extcon/extcon-adc-jack.txt | 60 +++++++++++++++++++
> .../devicetree/bindings/extcon/extcon-arizona.txt | 47 +++++++++++++++
> .../devicetree/bindings/extcon/extcon-bindings.txt | 36 +++++++++++
> .../devicetree/bindings/extcon/extcon-gpio.txt | 63 ++++++++++++++++++++
> .../devicetree/bindings/extcon/extcon-max14577.txt | 49 +++++++++++++++
> .../devicetree/bindings/extcon/extcon-max77693.txt | 56 +++++++++++++++++
> .../devicetree/bindings/extcon/extcon-max8997.txt | 49 +++++++++++++++
> .../devicetree/bindings/extcon/extcon-palmas.txt | 37 ++++++++++--
This is creating device tree bindings for MFD components as devices when
those MFD components aren't well isolated from the rest of the device.
If we need to add extcon bindings the device should have the flexibility
to decide where to add the properties, and really things should be set
up so there's less duplication in the documentation.
> +The following is the list of cables detected by the controller. Each
> +cable is assigned an identifier and client nodes use this identifies
> +to specify the cable which they are interested in.
> +
> + Cable ID
> + ----------------------------
> +
> + Mechanical 0
> + Microphone 1
> + Headphone 2
> + Line-out 3
> +
> +Example 1: An example of a extcon controller node is listed below.
> +
> + extcon: arizona-extcon {
The above doesn't entirely reflect what the hardware is capable of doing
- it reflects the default software configuration for the device but it's
got a wider feature set.
Attachment:
signature.asc
Description: Digital signature
