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: <20111205194545.GH7467@opensource.wolfsonmicro.com>
Date:	Mon, 5 Dec 2011 19:45:46 +0000
From:	Mark Brown <broonie@...nsource.wolfsonmicro.com>
To:	NeilBrown <neilb@...e.de>
Cc:	Dmitry Torokhov <dmitry.torokhov@...il.com>,
	MyungJoo Ham <myungjoo.ham@...il.com>,
	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>
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Tue, Dec 06, 2011 at 06:38:34AM +1100, NeilBrown wrote:

> Ahh..
> So to try to restate the requirements:

>  A "cable-port" can detect when a "cable" in inserted (or removed) and can
>  determine the "cable-type" which comprises:
>    - a "cable-name" which is an arbitrary label interpreted in the context of
>      the particular port
>    - 1 or more "cable-function" flags which indicate what functions the 
>      cable support.  A given port has a fixed set of "cable-functions" and 
>      for any given cable it will report true/false (present/absent, on/off)
>      for each cable-function.
> 
>  This full "cable-type" needs to be presented to user-space, and individual
>  cable-functions may need to be communicated to specific drivers to trigger a
>  'probe' function.

Yes, that seems broadly sane for me.

> Questions:
>   1/ Do we need to communicate anything to drivers apart from "cable-detect"?
>      i.e. are they quite cable of probing and identifying, or do they need to
>      be told what to look for?

Perhaps.

>   2/ Does it hurt to simply wake up all drivers that might be listening on
>      the cable or do we need individual wake-ups (notifiers) for each
>      cable-function?

I suspect not.

>   3/ Does anything in the kernel care about the cable-name, or is that only
>      interesting to user-space?

I suspect not.

Other people may have other opinions, though.
--
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/