Myunjoo/Chanwoo Ping... Could you please review this patch?
-jtc > > > Subject: Re: [PATCH] extcon : callback function to read cable > > > property > > > > > > I think the reason why we have extcon is in first place is to only > > > notify the clients of cable connection and disconnection and it is > > > up to the client to decide what else to do with the cable such as > > > finding which state it is in and other details. > > > So I feel this should not be handled in the extcon. > > > > > > However it is up to the maintainer to decide. > > > > Once the consumer gets the notification, it needs to take some action. > > One of the action is to read the cable properties. This can be done by > > proprietary calls which is known both to the consumer and the provider. > > My intention is to avoid this proprietary calls. Since both the > > provider and consumer are communicating with the extcon subsystem , I > > feel having a callback function of this kind would help to avoid the > > use of proprietary calls. Also I agree that extcon notifier chains are > > used to notify the cable state (attach/detach). But if a cable has > > more than two states (like the charger cable) how do we support it without > having a callback function like this? > > Let the maintainer take the final decision. > Well this use case will keep on growing if we start factor in this kind of > changes and that is why I am opposed to adding any other state. > Maintainer? > > > > >
