On Thu, 2012-10-11 at 01:20 +0000, Tc, Jenny wrote: > > From: anish kumar [mailto:anish198519851...@gmail.com] > > Sent: Wednesday, October 10, 2012 8:15 PM > > To: Tc, Jenny > > Cc: myungjoo....@samsung.com; cw00.c...@samsung.com; linux- > > ker...@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? > >
-- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/