linux-kernel - Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <20111130135847.68a6e4c6@notabene.brown>
Date:	Wed, 30 Nov 2011 13:58:47 +1100
From:	NeilBrown <neilb@...e.de>
To:	MyungJoo Ham <myungjoo.ham@...il.com>
Cc:	linux-kernel@...r.kernel.org,
	Linus Walleij <linus.walleij@...aro.org>,
	Arnd Bergmann <arnd@...db.de>,
	Mike Lockwood <lockwood@...roid.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Kyungmin Park <kyungmin.park@...sung.com>,
	Donggeun Kim <dg77.kim@...sung.com>, Greg KH <gregkh@...e.de>,
	Grant Likely <grant.likely@...retlab.ca>,
	Kalle Komierowski <karl.komierowski@...ricsson.com>,
	Johan PALSSON <johan.palsson@...ricsson.com>,
	Daniel WILLERUD <daniel.willerud@...ricsson.com>,
	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	Mark Brown <broonie@...nsource.wolfsonmicro.com>
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Tue, 29 Nov 2011 18:11:02 +0900 MyungJoo Ham <myungjoo.ham@...il.com>
wrote:

> 3. Allow the notifiee device drivers to register its specific
> interest. The interface would look like:
> int switch_register_interest(struct switch_dev *sdev, const char
> *cable_name, struct notifier_block *b);
> (the rationale is that the notifiee device does not need to know the
> detail about the switch dev configuration but for the name of the
> switch dev or notifier).
> or even
> int switch_register_interest(const char *switch_name, const char
> *cable_name, struct notifier_block *b);
> and allow notifee to forget about the sdev pointer as well. (and all
> the other APIs are for implementing notifier, not notifiee)

I'm surprised to find "cable_name" in there.  It is saying that multi-switch
is always used for cable-plug events.  If that is the case, then maybe the
name "multiswitch" is too generic.  Maybe this is a "cabledetect" function??

I'm wondering if a switch should be something much simpler - not even a
'device' necessarily.  Maybe it is more like a resource, like gpio or irq or
pwm or region or clock or ...

So each switch on a given board is identified by a number and any code that
wants to know about switch events needs to be given the magic number somehow
(in platform_data?) and does
  request_switch(switch_number)
  switch_register_interest(switch_number, notifier_block)

I don't know exactly how your "cable_name" would fit.  Does that just
identify the particular value that the switch has?  In that case
switch_callback could have an optional 'value' so the call back only happens
when the switch is set to that value (or set from that value).

If you need to make it appear in sysfs, write "switch_export" based on
"gpio_export".
If you want the switch to generate input events, write switch_keys based on
gpio_keys.

I guess my point is that a "switch" - even a "multiswitch" - is an extremely
generic concept and imposing too much semantics on all switches would be a
mistake.

On reflection... I think you said that a switch could have a bit-map of up to
32 bits with each bit representing a different cable type, and multiple
cables can be plugged in at the same time - is that correct?
If so, then why not just have multiple switches, one for each cable type.
The thing that detects the cables could then register a "switchchip" (like
gpiochip) that supports a number of switches all handled by the same code.  A
client would just register_interest with the individual switches that it
cares about - i.e. the individual cable(s).

Though I might have misunderstood something.

NeilBrown

Download attachment "signature.asc" of type "application/pgp-signature" (829 bytes)