Re: [PATCH v2 01/13] Documentation: add extcon devicetree bindings

[Robert Baldyga]

On 04/22/2014 09:51 PM, Mark Brown wrote:
> 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.

Those components has their own addresses on i2c bus, so they are,
technically, separate devices, and they can (should?) be described by
separate nodes. And I think it doesn't matter if they are grouped in one
chip.

However, it's easy to change it (give mfd master driver node to extcon),
and we can have extcon device defined without additional node, and then
parent node is an extcon node.

Best regards
Robert Baldyga
Samsung R&D Institute Poland

> 
>> +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.
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/