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: <CAH9JG2VTmhTiw=wf66rTZo0fZ4+-MhcAJzfEXzAL4Jybo89v+g@mail.gmail.com>
Date:	Sat, 26 Nov 2011 22:23:19 +0900
From:	Kyungmin Park <kmpark@...radead.org>
To:	Arnd Bergmann <arnd@...db.de>
Cc:	myungjoo.ham@...il.com, linux-kernel@...r.kernel.org,
	Mike Lockwood <lockwood@...roid.com>,
	Arve Hjønnevåg <arve@...roid.com>,
	Donggeun Kim <dg77.kim@...sung.com>, Greg KH <gregkh@...e.de>,
	Linus Walleij <linus.walleij@...aro.org>
Subject: Re: [RFC PATCH 0/3] introduce: Multistate Switch Class

On Fri, Nov 25, 2011 at 11:02 PM, Arnd Bergmann <arnd@...db.de> wrote:
> On Thursday 24 November 2011, MyungJoo Ham wrote:
>> For switch ports, which may have different types of cables
>> (USB, TA, HDMI, Analog A/V, and others), we often have seperated device
>> drivers that detect the state changes at the port and device drivers that
>> do something according to the state changes.
>>
>> For example, when MAX8997-MUIC detects a Charger cable insertion, another
>> device driver (such as MAX8903 charger, MAX8997 charger, Charger Manager,
>> or board file) needs to set charger current limit accordingly and when
>> MAX8997-MUIC detects a HDMI cable insertion, multimedia device drivers
>> need to do some operations accordingly.
>>
>> This patchset supports the usage of notifier for passing such information
>> between device drivers.
>>
>> Another issue is that at a single switch port, there might be multiple
>> and heterogeneous cables attached at the same time. Besides, the state
>> (Attached or Detached) of each cable may alter independently.
>>
>> In order to address such issues, Android kernel's "Switch" class seems to
>> be a good basis and we have implemented "Multistate Switch Class" based on
>> it. The "Switch" class code of Android kernel is GPL as well.
>
> 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?

Hi Arnd,

As you know, the 'pinmux' is based on the GPIO based MUX and changes
the pin state by device driver want.
but multistate switch provides the mechanism which notify the state
change and each device drivers handles it properly.
As described at cover letter, if MHL (Mobile HTML Link) is connected
to the phone, it switch the circuit to use MHL chip and notify the MHL
& HDMI power up. and detached power down the HDMI related chips.

Moreover new 30 pin connector is used, it can support more devices. In
this case we don't need to switch the circuit. Of course some pins are
need to changed  to MUXing purpose. but notify proper information to
each devices.

I think the 'pinmux' is controlled by each device drivers as passive
framework, however multistate switch is active way to know/notify each
devices works properly when external connector is attached to device
(e.g., phone)

BTW does pinmux framework provide the notification mechanism to device?

Thank you,
Kyungmin Park
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ