Message-ID: <CAJ0PZbRpoz+uK4QUAO4RG5bhsSpNvm5U-ROtbduXhnFTLMZ1VQ@mail.gmail.com>
Date:	Wed, 30 Nov 2011 15:40:48 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	NeilBrown <neilb@...e.de>
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 Wed, Nov 30, 2011 at 11:58 AM, NeilBrown <neilb@...e.de> wrote:
> 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??

Hmm.. then, would ("switch_name" and "node_name") or ("extcon_name"
and "cable_name") be better?
(extcon: external connect, which is the name I'm considering for now)

I'm focusing on an external connector or port that each physical port
may inhabit multiple cables at a time although it should support a
port that may inhabit a single cable only at a time. However, the
class could be used for other general "multistate mux" that connects
different device drivers.

>
> 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 ...

If we take the approach of GPIO or IRQ, providing a unique number for
each possible cable, we need to define the numbers at a board file
(bsp), device tree, or with some other mechanisms and pass the numbers
to notifiers (extcon/switch devices) and notifiees (devices using the
cable).

However, unlike GPIO or IRQ, we have more information available at
each node. A "Samsung Slate Dock" notifiee device driver will always
get notified via "Dock" cable of a given
extcon/multistate-switch-class device (notifier, "PortX"). I'm not
sure whether we need to make "Samsung Slate Dock" device driver to use
node "15" and let some other part in kernel define "15" as a "Dock"
cable of a multistate switch device "PortX".

In other words, for GPIO or IRQ, for a device driver X in coding time,
we don't know whether X will be using which "node" of a GPIO-chip or
IRQ-chip. However, for extcon/multistate-switch, we generally know
which "cable/node" of a extcon/multistate-switch device although we
don't know which extcon/multistate-switch device will be used.

Anyway, having no standard naming convention for cables is a obstruct
for that purpose. E.g., every "Dock" device drivers need to use the
cable name "Dock" to be supported. Thus, adding a suggested name list
could be done in the next iteration.

>
> 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?

Yes, correct.

> If so, then why not just have multiple switches, one for each cable type.

Not one for each cable type, One for each cable type and port. We may
have the same cable type attached to multiple different external
ports.
(one external port = one "switch_dev" object = cable detector)

> 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


Because an instance of "Cable-X's IO" device shoudl be able to
distinguish whether it is attached to a "Cable-X" of switch (or
extcon) "MAX8997-MUIC.0" or "MAX8997-MUIC.1", it seems that providing
a unique name for each cable type may make things more complex for
device drivers. By seperating the names of switch/extcon and
cable/port/node, we can implement device drivers of notifiers
(representing switch/extcon) and notifiees (handling or using
cable/port/node) may keep "cable name" constantly in their device
driver code: "MHL" device driver will use cable "MHL", "USB Host"
device driver will use cable "USB Host", and so on. We only need to
configure which device is waiting to be connected to which
extcon/switch with platform data: e.g., a device "mhl.0" is being
connected to "max8997-muic.0", a device "charger-manager.0" is being
connected to "max8997-muic.1".

Although I'm implementing with devices that have only one "extcon" for
now, I guess it'd better to assume that I'll start working on devices
with two or more soon.


-- 
MyungJoo Ham, Ph.D.
Mobile Software Platform Lab, DMC Business, Samsung Electronics
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists