linux-kernel - Re: [PATCH v4 01/12] misc: add driver for sequencer serial port

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:	Thu, 28 Oct 2010 14:14:14 -0400
From:	Linus Walleij <linus.ml.walleij@...il.com>
To:	cyril@...com
Cc:	"davinci-linux-open-source@...ux.davincidsp.com" 
	<davinci-linux-open-source@...ux.davincidsp.com>,
	"spi-devel-general@...ts.sourceforge.net" 
	<spi-devel-general@...ts.sourceforge.net>,
	"broonie@...nsource.wolfsonmicro.com" 
	<broonie@...nsource.wolfsonmicro.com>,
	"lrg@...mlogic.co.uk" <lrg@...mlogic.co.uk>,
	"dbrownell@...rs.sourceforge.net" <dbrownell@...rs.sourceforge.net>,
	"grant.likely@...retlab.ca" <grant.likely@...retlab.ca>,
	"linux-arm-kernel@...ts.infradead.org" 
	<linux-arm-kernel@...ts.infradead.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"rpurdie@...ys.net" <rpurdie@...ys.net>,
	Samuel Ortiz <sameo@...ux.intel.com>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [PATCH v4 01/12] misc: add driver for sequencer serial port

2010/10/28 Cyril Chemparathy <cyril@...com>:
> On 10/28/2010 11:49 AM, Linus Walleij wrote:
>> Why is this thing in drivers/misc?
>> drivers/mfd is IMHO the apropriate place for a driver like this, (...)
>
> Alan had raised the same concern earlier, and my response was:
>
>[Cyril]
>> Unlike MFDs, this device doesn't have cells with differing
>> functionality.  Instead it has functionally identical ports that can
>> operate in a variety of modes.  That said, does this still fit in with
>> other MFD drivers?  If so, I don't see a problem with moving it there.
>
> I don't see a problem with moving this into MFD, but this won't be able
> to use any of the functionality provided by mfd-core.

I think they do have differing functionality, though not in their
essence (hardware), they do get a clearly defined role at
run-time.

Sam will tell, but since you have subdrivers in other
subsystems MFD fits best IMHO.

What about the platform data passed into the MFD driver defines
what type of functionality will be assigned to each physical
block, from that you create the array of MFD cells to be spawn
and spawn it off. Then you have platform_driver:s in each
subsystem attaching to said cells. Shouldn't be too hard.

Yours,
Linus Walleij
--
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/