Messages in this thread | | | Subject | RE: [PATCH] extcon : callback function to read cable property | From | anish kumar <> | Date | Thu, 11 Oct 2012 22:47:40 +0900 |
| |
On Thu, 2012-10-11 at 01:20 +0000, Tc, Jenny wrote: > > From: anish kumar [mailto:anish198519851985@gmail.com] > > Sent: Wednesday, October 10, 2012 8:15 PM > > To: Tc, Jenny > > Cc: myungjoo.ham@samsung.com; cw00.choi@samsung.com; linux- > > kernel@vger.kernel.org > > 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? > >
| |