linux-kernel - RE: [PATCH] extcon : callback function to read cable property

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20ADAB092842284E95860F279283C56439BC4A@BGSMSX101.gar.corp.intel.com>
Date:	Thu, 11 Oct 2012 01:20:15 +0000
From:	"Tc, Jenny" <jenny.tc@...el.com>
To:	anish kumar <anish198519851985@...il.com>
CC:	"myungjoo.ham@...sung.com" <myungjoo.ham@...sung.com>,
	"cw00.choi@...sung.com" <cw00.choi@...sung.com>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH] extcon : callback function to read cable property

> From: anish kumar [mailto:anish198519851985@...il.com]
> Sent: Wednesday, October 10, 2012 8:15 PM
> To: Tc, Jenny
> Cc: myungjoo.ham@...sung.com; cw00.choi@...sung.com; linux-
> kernel@...r.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.