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]

Date:	Tue, 29 Nov 2011 18:11:02 +0900
From:	MyungJoo Ham <myungjoo.ham@...il.com>
To:	linux-kernel@...r.kernel.org
Cc:	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, Nov 29, 2011 at 2:53 AM, Arnd Bergmann <arnd@...db.de> wrote:
> On Sunday 27 November 2011, Linus Walleij wrote:
>> > How does this relate to the new "pinmux" subsystem that Linus Walleij
>> > maintains? Would it be useful to integrate your driver into pinmux
>> > instead of starting a new subsystem?
>>
>> Looks unrelated to pinmux but very useful.
>
> Ok, got it. So while pinmux controls the setting of some pins, this one
> generates software events when the state is changed from the outside.

For pinmux:
Besides, pinmux does not support multistate-muxing (you cannot set a
gpio pin to have multiple states at the same time) and focusses on
setting pins (device drivers set the GPIO pin configurations). The
target devices of multistate switch class (MSC) do not (actually,
cannot) control the setting of the switch proactively; it is done by
the physical hands of users (plugging in or out external cables). The
target device drivers (MSClass device driver) update switch_dev
information only when the cable states are changed by users.

For USB:
MSC is not for USB only. USB is just one of example cables. This needs
to support HDMI, Analog A/V I/O, Dock, and any other that may be
connected to a computer. (simply a "string" to MSC anyway)

For HID:
MSC is a simple notifier chain provider to provide bridges between
external-port-drivers and other notifiee device drivers and uevent
generator for external-port-drivers.
I'm a bit confused on using HID for the purpose.
Anyway, doesn't this mean that every device driver that gets
notifications from the external-port-drivers also need to be an HID
device? That'd mean that USB(either host/slave) drivers, Charger
drivers, Sound drivers, Video drivers, HDMI drivers, and many others
need to support HID in order to get this simple "plugged-in"
notification.

The target devices include (supported cable lists are not complete):
MAX8997 MUIC: a multi-pin port that may inhabit multiple cables (some
may mutually exclusive) including USB-HOST, USB, Travel Adaptor, HDMI,
Analog Audio / Video x Input / Output, Dock, and others.
FSA9480 USB Switch: USB / Travel Adaptor / HDMI / ...
MAX77693 (base driver soon to be released): same with if not more than
MAX8997 MUIC

We are notifying the changes in the states from MSC to both device
drivers (Charger, USB, Sound, Video, ...) and user spaces
(applications monitoring the cable insertion/removal).

For the next iteration, I'm considering the followings. It'd be much
appreciated if I could get some comments about those beforehand.
1. ABI documentation
2. move the location from /drivers/misc to an independent location.
/drivers/switch? /drivers/multistate-switch? /drivers/msc?
/drivers/mswitch? ...
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)

Cheers!

MyungJoo

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