mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: NeilBrown <neilb@suse.de>
To: MyungJoo Ham <myungjoo.ham@gmail.com>
Cc: linux-kernel@vger.kernel.org,
	"Linus Walleij" <linus.walleij@linaro.org>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Mike Lockwood" <lockwood@android.com>,
	"Arve Hjønnevåg" <arve@android.com>,
	"Kyungmin Park" <kyungmin.park@samsung.com>,
	"Donggeun Kim" <dg77.kim@samsung.com>, "Greg KH" <gregkh@suse.de>,
	"Grant Likely" <grant.likely@secretlab.ca>,
	"Kalle Komierowski" <karl.komierowski@stericsson.com>,
	"Johan PALSSON" <johan.palsson@stericsson.com>,
	"Daniel WILLERUD" <daniel.willerud@stericsson.com>,
	"Dmitry Torokhov" <dmitry.torokhov@gmail.com>,
	"Mark Brown" <broonie@opensource.wolfsonmicro.com>
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class
Date: Wed, 30 Nov 2011 13:58:47 +1100	[thread overview]
Message-ID: <20111130135847.68a6e4c6@notabene.brown> (raw)
In-Reply-To: <CAJ0PZbT8FcCq=6GzLxOhhpRvCbCaJJEhE9_2GXXT4P0XZp6H-w@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2683 bytes --]

On Tue, 29 Nov 2011 18:11:02 +0900 MyungJoo Ham <myungjoo.ham@gmail.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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]

  parent reply	other threads:[~2011-11-30  2:59 UTC|newest]

Thread overview: 44+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-24  2:03 MyungJoo Ham
2011-11-25 14:02 ` Arnd Bergmann
2011-11-26  5:46   ` MyungJoo Ham
2011-11-26 13:23   ` Kyungmin Park
2011-11-27 22:43   ` Linus Walleij
2011-11-27 23:08     ` Greg KH
2011-11-28  0:09       ` Dmitry Torokhov
2011-11-28  0:19         ` Greg KH
2011-11-28  9:03           ` Dmitry Torokhov
2011-11-28  1:31       ` NeilBrown
2011-11-28  7:27         ` Greg KH
2011-11-28  9:04           ` Dmitry Torokhov
2011-11-30  6:35             ` Greg KH
2011-11-30  6:58               ` MyungJoo Ham
2011-11-30  9:46                 ` Mark Brown
2011-11-30 13:28               ` Linus Walleij
2011-11-30 23:04                 ` NeilBrown
2011-12-01 13:38                   ` Linus Walleij
2011-11-28 13:04           ` Linus Walleij
2011-11-28 15:09             ` Morten CHRISTIANSEN
2011-11-30  6:34               ` Greg KH
2011-11-28 17:53     ` Arnd Bergmann
2011-11-29  9:11       ` MyungJoo Ham
2011-11-29  9:45         ` Linus Walleij
2011-11-29 13:59         ` Arnd Bergmann
2011-11-29 17:05           ` Dmitry Torokhov
2011-11-30  2:58         ` NeilBrown [this message]
2011-11-30  6:40           ` MyungJoo Ham
2011-11-30 22:56             ` NeilBrown
2011-11-30 23:17               ` Mark Brown
2011-11-30 23:25                 ` Dmitry Torokhov
2011-12-01  4:51                   ` MyungJoo Ham
2011-12-01  5:21                   ` NeilBrown
2011-12-01 11:34                     ` Mark Brown
2011-12-05  3:04                       ` NeilBrown
2011-12-05 12:06                         ` Mark Brown
2011-12-05 19:38                           ` NeilBrown
2011-12-05 19:45                             ` Mark Brown
2011-12-01  4:46               ` MyungJoo Ham
2011-12-07  9:31       ` Linus Walleij
2011-12-08  4:42         ` Kyungmin Park
2011-11-26 15:32 ` Greg KH
2011-11-29  8:18   ` MyungJoo Ham
2011-11-28 18:23 ` Mark Brown

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111130135847.68a6e4c6@notabene.brown \
    --to=neilb@suse.de \
    --cc=arnd@arndb.de \
    --cc=arve@android.com \
    --cc=broonie@opensource.wolfsonmicro.com \
    --cc=daniel.willerud@stericsson.com \
    --cc=dg77.kim@samsung.com \
    --cc=dmitry.torokhov@gmail.com \
    --cc=grant.likely@secretlab.ca \
    --cc=gregkh@suse.de \
    --cc=johan.palsson@stericsson.com \
    --cc=karl.komierowski@stericsson.com \
    --cc=kyungmin.park@samsung.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=lockwood@android.com \
    --cc=myungjoo.ham@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

Powered by JetHome