Граф коммитов

8 Коммитов

Автор SHA1 Сообщение Дата
David Brownell 8ae12a0d85 [PATCH] spi: simple SPI framework
This is the core of a small SPI framework, implementing the model of a
queue of messages which complete asynchronously (with thin synchronous
wrappers on top).

  - It's still less than 2KB of ".text" (ARM).  If there's got to be a
    mid-layer for something so simple, that's the right size budget.  :)

  - The guts use board-specific SPI device tables to build the driver
    model tree.  (Hardware probing is rarely an option.)

  - This version of Kconfig includes no drivers.  At this writing there
    are two known master controller drivers (PXA/SSP, OMAP MicroWire)
    and three protocol drivers (CS8415a, ADS7846, DataFlash) with LKML
    mentions of other drivers in development.

  - No userspace API.  There are several implementations to compare.
    Implement them like any other driver, and bind them with sysfs.

The changes from last version posted to LKML (on 11-Nov-2005) are minor,
and include:

  - One bugfix (removes a FIXME), with the visible effect of making device
    names be "spiB.C" where B is the bus number and C is the chipselect.

  - The "caller provides DMA mappings" mechanism now has kerneldoc, for
    DMA drivers that want to be fancy.

  - Hey, the framework init can be subsys_init.  Even though board init
    logic fires earlier, at arch_init ... since the framework init is
    for driver support, and the board init support uses static init.

  - Various additional spec/doc clarifications based on discussions
    with other folk.  It adds a brief "thank you" at the end, for folk
    who've helped nudge this framework into existence.

As I've said before, I think that "protocol tweaking" is the main support
that this driver framework will need to evolve.

From: Mark Underwood <basicmark@yahoo.com>

  Update the SPI framework to remove a potential priority inversion case by
  reverting to kmalloc if the pre-allocated DMA-safe buffer isn't available.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2006-01-13 16:29:54 -08:00
Evgeniy Polyakov 7672d0b544 [NET]: Add netlink connector.
Kernel connector - new userspace <-> kernel space easy to use
communication module which implements easy to use bidirectional
message bus using netlink as it's backend.  Connector was created to
eliminate complex skb handling both in send and receive message bus
direction.

Connector driver adds possibility to connect various agents using as
one of it's backends netlink based network.  One must register
callback and identifier. When driver receives special netlink message
with appropriate identifier, appropriate callback will be called.

From the userspace point of view it's quite straightforward:

	socket();
	bind();
	send();
	recv();

But if kernelspace want to use full power of such connections, driver
writer must create special sockets, must know about struct sk_buff
handling...  Connector allows any kernelspace agents to use netlink
based networking for inter-process communication in a significantly
easier way:

int cn_add_callback(struct cb_id *id, char *name, void (*callback) (void *));
void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask);

struct cb_id
{
	__u32			idx;
	__u32			val;
};

idx and val are unique identifiers which must be registered in
connector.h for in-kernel usage.  void (*callback) (void *) - is a
callback function which will be called when message with above idx.val
will be received by connector core.

Using connector completely hides low-level transport layer from it's
users.

Connector uses new netlink ability to have many groups in one socket.

[ Incorporating many cleanups and fixes by myself and
  Andrew Morton -DaveM ]

Signed-off-by: Evgeniy Polyakov <johnpol@2ka.mipt.ru>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-09-11 19:15:07 -07:00
Russell King a4e137ab14 [MFD] Add multimedia communication port core support
Add support for the core of the multimedia communication port
framework.  This is a port used to communicate with devices
with two DMA paths and a control path.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
2005-08-18 10:06:59 +01:00
Linus Torvalds 22a4427972 Merge master.kernel.org:/pub/scm/linux/kernel/git/gregkh/i2c-2.6 2005-07-12 15:54:36 -07:00
Sam Ravnborg d5950b4355 [NET]: add a top-level Networking menu to *config
Create a new top-level menu named "Networking" thus moving
net related options and protocol selection way from the drivers
menu and up on the top-level where they belong.

To implement this all architectures has to source "net/Kconfig" before
drivers/*/Kconfig in their Kconfig file. This change has been
implemented for all architectures.

Device drivers for ordinary NIC's are still to be found
in the Device Drivers section, but Bluetooth, IrDA and ax25
are located with their corresponding menu entries under the new
networking menu item.

Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
Signed-off-by: David S. Miller <davem@davemloft.net>
2005-07-11 21:03:49 -07:00
Jean Delvare ad2f931dcb [PATCH] I2C: Move hwmon drivers (1/3)
Part 1: Configuration files and Makefiles.

From: Jean Delvare <khali@linux-fr.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2005-07-11 14:14:31 -07:00
Brent Casavant e5d310b349 [PATCH] ioc4: CONFIG split
The SGI IOC4 I/O controller chip drivers are currently all configured by
CONFIG_BLK_DEV_SGIIOC4.  This is undesirable as not all IOC4 hardware features
are needed by all systems.

This patch adds two configuration variables, CONFIG_SGI_IOC4 for core IOC4
driver support (see patch 1/3 in this series for further explanation) and
CONFIG_SERIAL_SGI_IOC4 to independently enable serial port support.

Signed-off-by: Brent Casavant <bcasavan@sgi.com>
Acked-by: Pat Gefre <pfg@sgi.com>
Acked-by: Jeremy Higdon <jeremy@sgi.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
2005-06-21 18:46:32 -07:00
Linus Torvalds 1da177e4c3 Linux-2.6.12-rc2
Initial git repository build. I'm not bothering with the full history,
even though we have it. We can create a separate "historical" git
archive of that later if we want to, and in the meantime it's about
3.2GB when imported into git - space that would just make the early
git days unnecessarily complicated, when we don't have a lot of good
infrastructure for it.

Let it rip!
2005-04-16 15:20:36 -07:00