On Fri, Apr 25, 2014 at 03:19:59PM +0200, Robert Baldyga wrote: > On 04/22/2014 09:51 PM, Mark Brown wrote:
> >> .../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. That's definitely not true for the arizona devices, I haven't specifically checked for any of the others. It's all one device and the isolation isn't particularly solid.
signature.asc
Description: Digital signature
