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: <4CC9A03F.80401@ti.com>
Date:	Thu, 28 Oct 2010 12:09:35 -0400
From:	Cyril Chemparathy <cyril@...com>
To:	Linus Walleij <linus.ml.walleij@...il.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

On 10/28/2010 11:49 AM, Linus Walleij wrote:
> 2010/10/26 Cyril Chemparathy <cyril@...com>:
> 
>> TI's sequencer serial port (TI-SSP) is a jack-of-all-trades type of serial port
>> device.  It has a built-in programmable execution engine that can be programmed
>> to operate as almost any serial bus (I2C, SPI, EasyScale, and others).
>>
>> This patch adds a driver for this controller device.  The driver does not
>> expose a user-land interface.  Protocol drivers built on top of this layer are
>> expected to remain in-kernel.
> 
> Why is this thing in drivers/misc?
> 
> drivers/mfd is IMHO the apropriate place for a driver like this, and
> the subdrivers should be migrated to use mfd cells and platform
> drivers for the subdevices.
> 
> All functions and abstractions you create here look suspiciously
> lot like other MFD devices.
> 
> But please, beat me up if I'm wrong!

Alan had raised the same concern earlier, and my response was:

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

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