All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: atkbd.c: Unknown key released
From: Voluspa @ 2004-01-27 17:10 UTC (permalink / raw)
  To: Vojtech Pavlik; +Cc: linux-kernel

citerar Vojtech Pavlik:

> On Tue, Jan 27, 2004 at 08:16:59AM +0100, Voluspa wrote:
[...]
>
> > > > I keep getting the following in my syslog whenever I startx:
> >
> > In fact, it is preemptively written even _before_ I start X :-)
[...]
> Do you use 'kbdrate' in your bootup scripts? That's another one touching
> the keyboard controller directly, when there are ioctls for that.
>
> I guess I should modify to make the message not point not directly to X,
> but 'some application'.

Yes, 'kbdrate' is used here.

Mvh
Mats Johannesson


^ permalink raw reply

* Undeliverable:
From: System Administrator @ 2004-01-27 17:10 UTC (permalink / raw)
  To: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

[-- Attachment #1: Type: text/plain, Size: 206 bytes --]

******************  Virus Warning Message (on mgw.cosinecom.com)

Found virus WORM_MIMAIL.R in file document.pif
The uncleanable file was deleted.

*********************************************************

[-- Attachment #2: Type: text/plain, Size: 473 bytes --]

Your message

  To:      rfrye-irZh+ukUSxEybS5Ee8rs3A@public.gmane.org
  Subject: 
  Sent:    Tue, 27 Jan 2004 09:09:35 -0800

did not reach the following recipient(s):

RFRYE-UwdFWuI9Xr8El3j48+jJwQ@public.gmane.org on Tue, 27 Jan 2004 09:09:40 -0800
    The recipient name is not recognized
	The MTS-ID of the original message is: c=us;a= ;p=cosine
communica;l=IMCHUB10401271709CFP9S6PX
    MSEXCH:IMS:Cosine Communications:COSINE:IMCHUB1 0 (000C05A6) Unknown
Recipient



[-- Attachment #3: Type: message/rfc822, Size: 858 bytes --]

[-- Attachment #3.1.1: Type: text/plain, Size: 84 bytes --]

The message contains Unicode characters and has been sent as a binary
attachment.



[-- Attachment #3.1.2: Type: text/plain, Size: 190 bytes --]


******************  Virus Warning Message (on mgw.cosinecom.com)

document.pif was removed from here because it contained a virus.

*********************************************************

^ permalink raw reply

* Re: Special promisc receive mode
From: Andy Lutomirski @ 2004-01-27 17:09 UTC (permalink / raw)
  To: Karel Kulhavý; +Cc: linux-kernel
In-Reply-To: <fa.ijk3qim.15ls9ju@ifi.uio.no>

Try ebtables (http://ebtables.sourceforge.net/).  You'll need to add 
eth0 to a bridge first, though.

--Andy

Karel Kulhavý wrote:

> Hello
> 
> I need to tell kernel that e. g. eth0 is a point-to-point link and that every
> ethernet frame should be treated this way:
> 1) Replace destination MAC with MAC of the eth0 network card
> 2) Process as normally
> 
> I tried to set up promisc mode but it seems to not work - it looks like the
> frames are intercepted, however are not treated as destinated for my host (are
> not forwared etc.)
> 
> Cl<
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

^ permalink raw reply

* [U-Boot-Users] Boot Count Limit
From: Jeff Angielski @ 2004-01-27 17:07 UTC (permalink / raw)
  To: u-boot

Has anybody written the small application that resets the bootcount as
per the following description:

"It is the responsibility of some application code (typically a Linux
application) to reset the variable bootcount, thus allowing for more
boot cycles."

From the u-boot documentation site:

http://www.denx.de/twiki/bin/view/DULG/UBootBootCountLimit

If so, can you send it my way or tell me where to get it?  I am trying
to not recreate the wheel yet again.... :)

Thanks,
Jeff Angielski
The PTR Group

^ permalink raw reply

* [PATCH][2.6] Update NEC VRC4171 PCMCIA driver
From: Yoichi Yuasa @ 2004-01-27 17:03 UTC (permalink / raw)
  To: Ralf Baechle; +Cc: yuasa, linux-mips

Hello Ralf,

I updated the patch for VRC4171 PCMCIA driver.
This is the latest driver for VRC4171 PCMCIA.

This patch exists for HEAD of linux-mips.org CVS.
Please apply this patch.

Yoichi

diff -urN -X dontdiff linux-orig/drivers/pcmcia/Kconfig linux/drivers/pcmcia/Kconfig
--- linux-orig/drivers/pcmcia/Kconfig	Fri Jan 16 01:21:24 2004
+++ linux/drivers/pcmcia/Kconfig	Sat Jan 17 11:34:29 2004
@@ -121,6 +121,10 @@
 	bool
 	default y if ISA && !ARCH_SA1100 && !ARCH_CLPS711X
 
+config PCMCIA_VRC4171
+	tristate "NEC VRC4171 Card Controllers support"
+	depends on VRC4171 && PCMCIA
+
 config PCMCIA_VRC4173
 	tristate "NEC VRC4173 CARDU support"
 	depends on CPU_VR41XX && PCI && PCMCIA
diff -urN -X dontdiff linux-orig/drivers/pcmcia/Makefile linux/drivers/pcmcia/Makefile
--- linux-orig/drivers/pcmcia/Makefile	Fri Jan 16 01:21:24 2004
+++ linux/drivers/pcmcia/Makefile	Sat Jan 17 11:34:29 2004
@@ -11,6 +11,7 @@
 obj-$(CONFIG_HD64465_PCMCIA)		+= hd64465_ss.o
 obj-$(CONFIG_PCMCIA_SA1100)		+= sa1100_cs.o
 obj-$(CONFIG_PCMCIA_SA1111)		+= sa1111_cs.o
+obj-$(CONFIG_PCMCIA_VRC4171)		+= vrc4171_card.o
 obj-$(CONFIG_PCMCIA_VRC4173)		+= vrc4173_cardu.o
 
 pcmcia_core-objs-y				:= cistpl.o rsrc_mgr.o bulkmem.o cs.o
diff -urN -X dontdiff linux-orig/drivers/pcmcia/vrc4171_card.c linux/drivers/pcmcia/vrc4171_card.c
--- linux-orig/drivers/pcmcia/vrc4171_card.c	Thu Jan  1 09:00:00 1970
+++ linux/drivers/pcmcia/vrc4171_card.c	Wed Jan 28 01:19:47 2004
@@ -0,0 +1,744 @@
+/*
+ * vrc4171_card.c, NEC VRC4171 Card Controller driver for Socket Services.
+ *
+ * Copyright (C) 2003  Yoichi Yuasa <yuasa@hh.iij4u.or.jp>
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation; either version 2 of the License, or
+ *  (at your option) any later version.
+ *
+ *  This program is distributed in the hope that it will be useful,
+ *  but WITHOUT ANY WARRANTY; without even the implied warranty of
+ *  MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ *  GNU General Public License for more details.
+ *
+ *  You should have received a copy of the GNU General Public License
+ *  along with this program; if not, write to the Free Software
+ *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ */
+#include <linux/init.h>
+#include <linux/ioport.h>
+#include <linux/interrupt.h>
+#include <linux/module.h>
+#include <linux/spinlock.h>
+#include <linux/sched.h>
+#include <linux/types.h>
+
+#include <asm/io.h>
+#include <asm/vr41xx/vrc4171.h>
+
+#include <pcmcia/ss.h>
+
+#include "i82365.h"
+
+MODULE_DESCRIPTION("NEC VRC4171 Card Controllers driver for Socket Services");
+MODULE_AUTHOR("Yoichi Yuasa <yuasa@hh.iij4u.or.jp>");
+MODULE_LICENSE("GPL");
+
+#define CARD_MAX_SLOTS		2
+#define CARD_SLOTA		0
+#define CARD_SLOTB		1
+#define CARD_SLOTB_OFFSET	0x40
+
+#define CARD_MEM_START		0x10000000
+#define CARD_MEM_END		0x13ffffff
+#define CARD_MAX_MEM_OFFSET	0x3ffffff
+#define CARD_MAX_MEM_SPEED	1000
+
+#define CARD_CONTROLLER_INDEX	0x03e0
+#define CARD_CONTROLLER_DATA	0x03e1
+#define CARD_CONTROLLER_SIZE	2
+ /* Power register */
+  #define VPP_GET_VCC		0x01
+  #define POWER_ENABLE		0x10
+ #define CARD_VOLTAGE_SENSE	0x1f
+  #define VCC_3VORXV_CAPABLE	0x00
+  #define VCC_XV_ONLY		0x01
+  #define VCC_3V_CAPABLE	0x02
+  #define VCC_5V_ONLY		0x03
+ #define CARD_VOLTAGE_SELECT	0x2f
+  #define VCC_3V		0x01
+  #define VCC_5V		0x00
+  #define VCC_XV		0x02
+  #define VCC_STATUS_3V		0x02
+  #define VCC_STATUS_5V		0x01
+  #define VCC_STATUS_XV		0x03
+ #define GLOBAL_CONTROL		0x1e
+  #define EXWRBK		0x04
+  #define IRQPM_EN		0x08
+  #define CLRPMIRQ		0x10
+
+#define IO_MAX_MAPS	2
+#define MEM_MAX_MAPS	5
+
+enum {
+	SLOT_PROBE = 0,
+	SLOT_NOPROBE_IO,
+	SLOT_NOPROBE_MEM,
+	SLOT_NOPROBE_ALL
+};
+
+typedef struct vrc4171_socket {
+	int noprobe;
+	struct pcmcia_socket pcmcia_socket;
+	char name[24];
+	int csc_irq;
+	int io_irq;
+} vrc4171_socket_t;
+
+static vrc4171_socket_t vrc4171_sockets[CARD_MAX_SLOTS];
+static int vrc4171_slotb = SLOTB_IS_NONE;
+static unsigned int vrc4171_irq;
+static uint16_t vrc4171_irq_mask = 0xdeb8;
+
+static inline uint8_t exca_read_byte(int slot, uint8_t index)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	return inb(CARD_CONTROLLER_DATA);
+}
+
+static inline uint16_t exca_read_word(int slot, uint8_t index)
+{
+	uint16_t data;
+
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index++, CARD_CONTROLLER_INDEX);
+	data = inb(CARD_CONTROLLER_DATA);
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	data |= ((uint16_t)inb(CARD_CONTROLLER_DATA)) << 8;
+
+	return data;
+}
+
+static inline uint8_t exca_write_byte(int slot, uint8_t index, uint8_t data)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	outb(data, CARD_CONTROLLER_DATA);
+
+	return data;
+}
+
+static inline uint16_t exca_write_word(int slot, uint8_t index, uint16_t data)
+{
+	if (slot == CARD_SLOTB)
+		index += CARD_SLOTB_OFFSET;
+
+	outb(index++, CARD_CONTROLLER_INDEX);
+	outb(data, CARD_CONTROLLER_DATA);
+
+	outb(index, CARD_CONTROLLER_INDEX);
+	outb((uint8_t)(data >> 8), CARD_CONTROLLER_DATA);
+
+	return data;
+}
+
+static inline int search_nonuse_irq(void)
+{
+	int i;
+
+	for (i = 0; i < 16; i++) {
+		if (vrc4171_irq_mask & (1 << i)) {
+			vrc4171_irq_mask &= ~(1 << i);
+			return i;
+		}
+	}
+
+	return -1;
+}
+
+static int pccard_init(struct pcmcia_socket *sock)
+{
+	vrc4171_socket_t *socket;
+	unsigned int slot;
+
+	sock->features |= SS_CAP_PCCARD | SS_CAP_PAGE_REGS;
+	sock->irq_mask = 0;
+	sock->map_size = 0x1000;
+	sock->pci_irq = vrc4171_irq;
+
+	slot = sock->sock;
+	socket = &vrc4171_sockets[slot];
+	socket->csc_irq = search_nonuse_irq();
+	socket->io_irq = search_nonuse_irq();
+
+	return 0;
+}
+
+static int pccard_suspend(struct pcmcia_socket *sock)
+{
+	return -EINVAL;
+}
+
+static int pccard_get_status(struct pcmcia_socket *sock, u_int *value)
+{
+	unsigned int slot;
+	uint8_t status, sense;
+	u_int val = 0;
+
+	if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || value == NULL)
+		return -EINVAL;
+
+	slot = sock->sock;
+
+	status = exca_read_byte(slot, I365_STATUS);
+	if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) {
+		if (status & I365_CS_STSCHG)
+			val |= SS_STSCHG;
+	} else {
+		if (!(status & I365_CS_BVD1))
+			val |= SS_BATDEAD;
+		else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1)
+			val |= SS_BATWARN;
+	}
+	if ((status & I365_CS_DETECT) == I365_CS_DETECT)
+		val |= SS_DETECT;
+	if (status & I365_CS_WRPROT)
+		val |= SS_WRPROT;
+	if (status & I365_CS_READY)
+		val |= SS_READY;
+	if (status & I365_CS_POWERON)
+		val |= SS_POWERON;
+
+	sense = exca_read_byte(slot, CARD_VOLTAGE_SENSE);
+	switch (sense) {
+	case VCC_3VORXV_CAPABLE:
+		val |= SS_3VCARD | SS_XVCARD;
+		break;
+	case VCC_XV_ONLY:
+		val |= SS_XVCARD;
+		break;
+	case VCC_3V_CAPABLE:
+		val |= SS_3VCARD;
+		break;
+	default:
+		/* 5V only */
+		break;
+	}
+
+	*value = val;
+
+	return 0;
+}
+
+static inline u_char get_Vcc_value(uint8_t voltage)
+{
+	switch (voltage) {
+	case VCC_STATUS_3V:
+		return 33;
+	case VCC_STATUS_5V:
+		return 50;
+	default:
+		break;
+	}
+
+	return 0;
+}
+
+static inline u_char get_Vpp_value(uint8_t power, u_char Vcc)
+{
+	if ((power & 0x03) == 0x01 || (power & 0x03) == 0x02)
+		return Vcc;
+
+	return 0;
+}
+
+static int pccard_get_socket(struct pcmcia_socket *sock, socket_state_t *state)
+{
+	unsigned int slot;
+	uint8_t power, voltage, control, cscint;
+
+	if (sock == NULL || sock->sock >= CARD_MAX_SLOTS || state == NULL)
+		return -EINVAL;
+
+	slot = sock->sock;
+
+	power = exca_read_byte(slot, I365_POWER);
+	voltage = exca_read_byte(slot, CARD_VOLTAGE_SELECT);
+
+	state->Vcc = get_Vcc_value(voltage);
+	state->Vpp = get_Vpp_value(power, state->Vcc);
+
+	state->flags = 0;
+	if (power & POWER_ENABLE)
+		state->flags |= SS_PWR_AUTO;
+	if (power & I365_PWR_OUT)
+		state->flags |= SS_OUTPUT_ENA;
+
+	control = exca_read_byte(slot, I365_INTCTL);
+	if (control & I365_PC_IOCARD)
+		state->flags |= SS_IOCARD;
+	if (!(control & I365_PC_RESET))
+		state->flags |= SS_RESET;
+
+        cscint = exca_read_byte(slot, I365_CSCINT);
+	state->csc_mask = 0;
+	if (state->flags & SS_IOCARD) {
+		if (cscint & I365_CSC_STSCHG)
+			state->flags |= SS_STSCHG;
+	} else {
+		if (cscint & I365_CSC_BVD1)  
+			state->csc_mask |= SS_BATDEAD;
+		if (cscint & I365_CSC_BVD2)  
+			state->csc_mask |= SS_BATWARN;
+	}
+	if (cscint & I365_CSC_READY)
+		state->csc_mask |= SS_READY;
+	if (cscint & I365_CSC_DETECT)
+		state->csc_mask |= SS_DETECT;
+
+	return 0;
+}
+
+static inline uint8_t set_Vcc_value(u_char Vcc)
+{
+	switch (Vcc) {
+	case 33:
+		return VCC_3V;
+	case 50:
+		return VCC_5V;
+	}
+
+	/* Small voltage is chosen for safety. */
+	return VCC_3V;
+}
+
+static int pccard_set_socket(struct pcmcia_socket *sock, socket_state_t *state)
+{
+	vrc4171_socket_t *socket;
+	unsigned int slot;
+	uint8_t voltage, power, control, cscint;
+
+	if (sock == NULL || sock->sock >= CARD_MAX_SLOTS ||
+	    (state->Vpp != state->Vcc && state->Vpp != 0) ||
+	    (state->Vcc != 50 && state->Vcc != 33 && state->Vcc != 0))
+		return -EINVAL;
+
+	slot = sock->sock;
+	socket = &vrc4171_sockets[slot];
+
+	spin_lock_irq(&sock->lock);
+
+	voltage = set_Vcc_value(state->Vcc);
+	exca_write_byte(slot, CARD_VOLTAGE_SELECT, voltage);
+
+	power = POWER_ENABLE;
+	if (state->Vpp == state->Vcc)
+		power |= VPP_GET_VCC;
+	if (state->flags & SS_OUTPUT_ENA)
+		power |= I365_PWR_OUT;
+	exca_write_byte(slot, I365_POWER, power);
+
+	control = 0;
+	if (state->io_irq != 0)
+		control |= socket->io_irq;
+	if (state->flags & SS_IOCARD)
+		control |= I365_PC_IOCARD;
+	if (state->flags & SS_RESET)
+		control	&= ~I365_PC_RESET;
+	else
+		control |= I365_PC_RESET;
+	exca_write_byte(slot, I365_INTCTL, control);
+
+        cscint = 0;
+        exca_write_byte(slot, I365_CSCINT, cscint);
+	exca_read_byte(slot, I365_CSC);	/* clear CardStatus change */
+	if (state->csc_mask != 0)
+		cscint |= socket->csc_irq << 8;
+	if (state->flags & SS_IOCARD) {
+		if (state->csc_mask & SS_STSCHG)
+			cscint |= I365_CSC_STSCHG;
+	} else {
+		if (state->csc_mask & SS_BATDEAD)
+			cscint |= I365_CSC_BVD1;
+		if (state->csc_mask & SS_BATWARN)
+			cscint |= I365_CSC_BVD2;
+	}
+	if (state->csc_mask & SS_READY)
+		cscint |= I365_CSC_READY;
+	if (state->csc_mask & SS_DETECT)
+		cscint |= I365_CSC_DETECT;
+        exca_write_byte(slot, I365_CSCINT, cscint);
+
+	spin_unlock_irq(&sock->lock);
+
+	return 0;
+}
+
+static int pccard_set_io_map(struct pcmcia_socket *sock, struct pccard_io_map *io)
+{
+	unsigned int slot;
+	uint8_t ioctl, addrwin;
+	u_char map;
+
+	if (sock == NULL || sock->sock >= CARD_MAX_SLOTS ||
+	    io == NULL || io->map >= IO_MAX_MAPS ||
+	    io->start > 0xffff || io->stop > 0xffff || io->start > io->stop)
+		return -EINVAL;
+
+	slot = sock->sock;
+	map = io->map;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_IO(map)) {
+		addrwin &= ~I365_ENA_IO(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	exca_write_word(slot, I365_IO(map)+I365_W_START, io->start);
+	exca_write_word(slot, I365_IO(map)+I365_W_STOP, io->stop);
+
+	ioctl = 0;
+	if (io->speed > 0)
+		ioctl |= I365_IOCTL_WAIT(map);
+	if (io->flags & MAP_16BIT)
+		ioctl |= I365_IOCTL_16BIT(map);
+	if (io->flags & MAP_AUTOSZ)
+		ioctl |= I365_IOCTL_IOCS16(map);
+	if (io->flags & MAP_0WS)
+		ioctl |= I365_IOCTL_0WS(map);
+	exca_write_byte(slot, I365_IOCTL, ioctl);
+
+	if (io->flags & MAP_ACTIVE) {
+		addrwin |= I365_ENA_IO(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	return 0;
+}
+
+static int pccard_set_mem_map(struct pcmcia_socket *sock, struct pccard_mem_map *mem)
+{
+	unsigned int slot;
+	uint16_t start, stop, offset;
+	uint8_t addrwin;
+	u_char map;
+
+	if (sock == NULL || sock->sock >= CARD_MAX_SLOTS ||
+	    mem == NULL || mem->map >= MEM_MAX_MAPS ||
+	    mem->sys_start < CARD_MEM_START || mem->sys_start > CARD_MEM_END ||
+	    mem->sys_stop < CARD_MEM_START || mem->sys_stop > CARD_MEM_END ||
+	    mem->sys_start > mem->sys_stop ||
+	    mem->card_start > CARD_MAX_MEM_OFFSET ||
+	    mem->speed > CARD_MAX_MEM_SPEED)
+		return -EINVAL;
+
+	slot = sock->sock;
+	map = mem->map;
+
+	addrwin = exca_read_byte(slot, I365_ADDRWIN);
+	if (addrwin & I365_ENA_MEM(map)) {
+		addrwin &= ~I365_ENA_MEM(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	start = (mem->sys_start >> 12) & 0x3fff;
+	if (mem->flags & MAP_16BIT)
+		start |= I365_MEM_16BIT;
+	exca_write_word(slot, I365_MEM(map)+I365_W_START, start);
+
+	stop = (mem->sys_stop >> 12) & 0x3fff;
+	switch (mem->speed) {
+	case 0:
+		break;
+	case 1:
+		stop |= I365_MEM_WS0;
+		break;
+	case 2:
+		stop |= I365_MEM_WS1;
+		break;
+	default:
+		stop |= I365_MEM_WS0 | I365_MEM_WS1;
+		break;
+	}
+	exca_write_word(slot, I365_MEM(map)+I365_W_STOP, stop);
+
+	offset = (mem->card_start >> 12) & 0x3fff;
+	if (mem->flags & MAP_ATTRIB)
+		offset |= I365_MEM_REG;
+	if (mem->flags & MAP_WRPROT)
+		offset |= I365_MEM_WRPROT;
+	exca_write_word(slot, I365_MEM(map)+I365_W_OFF, offset);
+
+	if (mem->flags & MAP_ACTIVE) {
+		addrwin |= I365_ENA_MEM(map);
+		exca_write_byte(slot, I365_ADDRWIN, addrwin);
+	}
+
+	return 0;
+}
+
+static struct pccard_operations vrc4171_pccard_operations = {
+	.init			= pccard_init,
+	.suspend		= pccard_suspend,
+	.get_status		= pccard_get_status,
+	.get_socket		= pccard_get_socket,
+	.set_socket		= pccard_set_socket,
+	.set_io_map		= pccard_set_io_map,
+	.set_mem_map		= pccard_set_mem_map,
+};
+
+static inline unsigned int get_events(int slot)
+{
+	unsigned int events = 0;
+	uint8_t status, csc;
+
+	status = exca_read_byte(slot, I365_STATUS);
+	csc = exca_read_byte(slot, I365_CSC);
+
+	if (exca_read_byte(slot, I365_INTCTL) & I365_PC_IOCARD) {
+		if ((csc & I365_CSC_STSCHG) && (status & I365_CS_STSCHG))
+			events |= SS_STSCHG;
+	} else {
+		if (csc & (I365_CSC_BVD1 | I365_CSC_BVD2)) {
+			if (!(status & I365_CS_BVD1))
+				events |= SS_BATDEAD;
+			else if ((status & (I365_CS_BVD1 | I365_CS_BVD2)) == I365_CS_BVD1)
+				events |= SS_BATWARN;
+		}
+	}
+	if ((csc & I365_CSC_READY) && (status & I365_CS_READY))
+		events |= SS_READY;
+	if ((csc & I365_CSC_DETECT) && ((status & I365_CS_DETECT) == I365_CS_DETECT))
+		events |= SS_DETECT;
+
+	return events;
+}
+
+static irqreturn_t pccard_interrupt(int irq, void *dev_id, struct pt_regs *regs)
+{
+	vrc4171_socket_t *socket;
+	unsigned int events;
+	irqreturn_t retval = IRQ_NONE;
+	uint16_t status;
+
+	status = vrc4171_get_irq_status();
+	if (status & IRQ_A) {
+		socket = &vrc4171_sockets[CARD_SLOTA];
+		if (socket->noprobe == SLOT_PROBE) {
+			if (status & (1 << socket->csc_irq)) {
+				events = get_events(CARD_SLOTA);
+				if (events != 0) {
+					pcmcia_parse_events(&socket->pcmcia_socket, events);
+					retval = IRQ_HANDLED;
+				}
+			}
+		}
+	}
+
+	if (status & IRQ_B) {
+		socket = &vrc4171_sockets[CARD_SLOTB];
+		if (socket->noprobe == SLOT_PROBE) {
+			if (status & (1 << socket->csc_irq)) {
+				events = get_events(CARD_SLOTB);
+				if (events != 0) {
+					pcmcia_parse_events(&socket->pcmcia_socket, events);
+					retval = IRQ_HANDLED;
+				}
+			}
+		}
+	}
+
+	return retval;
+}
+
+static inline void reserve_using_irq(int slot)
+{
+	unsigned int irq;
+
+	irq = exca_read_byte(slot, I365_INTCTL);
+	irq &= 0x0f;
+	vrc4171_irq_mask &= ~(1 << irq);
+
+	irq = exca_read_byte(slot, I365_CSCINT);
+	irq = (irq & 0xf0) >> 4;
+	vrc4171_irq_mask &= ~(1 << irq);
+}
+
+static int __devinit vrc4171_add_socket(int slot)
+{
+	vrc4171_socket_t *socket;
+	int retval;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return -EINVAL;
+
+	socket = &vrc4171_sockets[slot];
+	if (socket->noprobe != SLOT_PROBE) {
+		uint8_t addrwin;
+
+		switch (socket->noprobe) {
+		case SLOT_NOPROBE_MEM:
+			addrwin = exca_read_byte(slot, I365_ADDRWIN);
+			addrwin &= 0x1f;
+			exca_write_byte(slot, I365_ADDRWIN, addrwin);
+			break;
+		case SLOT_NOPROBE_IO:
+			addrwin = exca_read_byte(slot, I365_ADDRWIN);
+			addrwin &= 0xc0;
+			exca_write_byte(slot, I365_ADDRWIN, addrwin);
+			break;
+		default:
+			break;
+		}
+
+		reserve_using_irq(slot);
+
+		return 0;
+	}
+
+	sprintf(socket->name, "NEC VRC4171 Card Slot %1c", 'A' + slot);
+
+	socket->pcmcia_socket.ops = &vrc4171_pccard_operations;
+
+	retval = pcmcia_register_socket(&socket->pcmcia_socket);
+	if (retval != 0)
+		return retval;
+
+	exca_write_byte(slot, I365_ADDRWIN, 0);
+
+	exca_write_byte(slot, GLOBAL_CONTROL, 0);
+
+	return 0;
+}
+
+static void vrc4171_remove_socket(int slot)
+{
+	vrc4171_socket_t *socket;
+
+	if (slot >= CARD_MAX_SLOTS)
+		return;
+
+	socket = &vrc4171_sockets[slot];
+
+	pcmcia_unregister_socket(&socket->pcmcia_socket);
+}
+
+static int __devinit vrc4171_card_setup(char *options)
+{
+	if (options == NULL || *options == '\0')
+		return 0;
+
+	if (strncmp(options, "irq:", 4) == 0) {
+		int irq;
+		options += 4;
+		irq = simple_strtoul(options, &options, 0);
+		if (irq >= 0 && irq < NR_IRQS)
+			vrc4171_irq = irq;
+
+		if (*options != ',')
+			return 0;
+		options++;
+	}
+
+	if (strncmp(options, "slota:", 6) == 0) {
+		options += 6;
+		if (*options != '\0') {
+			if (strncmp(options, "memnoprobe", 10) == 0) {
+				vrc4171_sockets[CARD_SLOTA].noprobe = SLOT_NOPROBE_MEM;
+				options += 10;
+			} else if (strncmp(options, "ionoprobe", 9) == 0) {
+				vrc4171_sockets[CARD_SLOTA].noprobe = SLOT_NOPROBE_IO;
+				options += 9;
+			} else if ( strncmp(options, "noprobe", 7) == 0) {
+				vrc4171_sockets[CARD_SLOTA].noprobe = SLOT_NOPROBE_ALL;
+				options += 7;
+			}
+
+			if (*options != ',')
+				return 0;
+			options++;
+		} else
+			return 0;
+
+	}
+
+	if (strncmp(options, "slotb:", 6) == 0) {
+		options += 6;
+		if (*options != '\0') {
+			if (strncmp(options, "pccard", 6) == 0) {
+				vrc4171_slotb = SLOTB_IS_PCCARD;
+				options += 6;
+			} else if (strncmp(options, "cf", 2) == 0) {
+				vrc4171_slotb = SLOTB_IS_CF;
+				options += 2;
+			} else if (strncmp(options, "flashrom", 8) == 0) {
+				vrc4171_slotb = SLOTB_IS_FLASHROM;
+				options += 8;
+			} else if (strncmp(options, "none", 4) == 0) {
+				vrc4171_slotb = SLOTB_IS_NONE;
+				options += 4;
+			}
+
+			if (*options != ',')
+				return 0;
+			options++;
+
+			if (strncmp(options, "memnoprobe", 10) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOT_NOPROBE_MEM;
+			if (strncmp(options, "ionoprobe", 9) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOT_NOPROBE_IO;
+			if (strncmp(options, "noprobe", 7) == 0)
+				vrc4171_sockets[CARD_SLOTB].noprobe = SLOT_NOPROBE_ALL;
+		}
+	}
+
+	return 0;
+}
+
+__setup("vrc4171_card=", vrc4171_card_setup);
+
+static int __devinit vrc4171_card_init(void)
+{
+	int retval, slot;
+
+	vrc4171_set_multifunction_pin(vrc4171_slotb);
+
+	if (request_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE,
+	                       "NEC VRC4171 Card Controller") == NULL)
+		return -EBUSY;
+
+	for (slot = 0; slot < CARD_MAX_SLOTS; slot++) {
+		if (slot == CARD_SLOTB && vrc4171_slotb == SLOTB_IS_NONE)
+			break;
+
+		retval = vrc4171_add_socket(slot);
+		if (retval != 0)
+			return retval;
+	}
+
+	retval = request_irq(vrc4171_irq, pccard_interrupt, SA_SHIRQ,
+	                     "NEC VRC4171 Card Controller", vrc4171_sockets);
+	if (retval < 0) {
+		for (slot = 0; slot < CARD_MAX_SLOTS; slot++)
+			vrc4171_remove_socket(slot);
+
+		return retval;
+	}
+
+	printk(KERN_INFO "NEC VRC4171 Card Controller, connected to IRQ %d\n", vrc4171_irq);
+
+	return 0;
+}
+
+static void __devexit vrc4171_card_exit(void)
+{
+	int slot;
+
+	for (slot = 0; slot < CARD_MAX_SLOTS; slot++)
+		vrc4171_remove_socket(slot);
+
+	release_region(CARD_CONTROLLER_INDEX, CARD_CONTROLLER_SIZE);
+}
+
+module_init(vrc4171_card_init);
+module_exit(vrc4171_card_exit);
diff -urN -X dontdiff linux-orig/include/pcmcia/cs_types.h linux/include/pcmcia/cs_types.h
--- linux-orig/include/pcmcia/cs_types.h	Sun Dec 21 10:45:59 2003
+++ linux/include/pcmcia/cs_types.h	Sat Jan 17 23:29:57 2004
@@ -36,7 +36,7 @@
 #include <sys/types.h>
 #endif
 
-#ifdef __arm__
+#if defined(__arm__) || defined(__mips__)
 typedef u_int   ioaddr_t;
 #else
 typedef u_short	ioaddr_t;

^ permalink raw reply

* RE: List noise.
From: Brown, Len @ 2004-01-27 17:00 UTC (permalink / raw)
  To: David Woodhouse, Dave Jones; +Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f

Sure, I'm open to moving the list off sourceforge if there is clearly a
better choice.  Two other problems we've seen on sf are
1. latency is sometimes huge
2. archives sometimes unavailable, and not indexed by google.

In the mean-time, here are the mailman spam filters I've got on SF, a
couple I've added in the last 30-minutes.  It doesn't look like it can
search for a _missing_ field -- only positive matches.  I'm sure open to
suggestions for further improvement.

Thanks,
-Len

# Lines that *start* with a '#' are comments.
to: friend-6zcLuMBsFRvQT0dZR+AlfA@public.gmane.org
message-id: relay.comanche.denmark.eu
message-id *externalmx.vasoftware.com*
from: list-pJMVowSF+OPQT0dZR+AlfA@public.gmane.org
from: .*@uplinkpro.com
X-Spam-Flag: YES
Content-Type: text/html
Auto-Submitted: auto-generated
Precedence: bulk
Subject: *Returned mail*
charset="Windows-1252"


> -----Original Message-----
> From: acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org 
> [mailto:acpi-devel-admin-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org] On Behalf Of 
> David Woodhouse
> Sent: Tuesday, January 27, 2004 10:00 AM
> To: Dave Jones
> Cc: acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> Subject: Re: [ACPI] List noise.
> 
> 
> On Tue, 2004-01-27 at 14:41 +0000, Dave Jones wrote:
> > On Tue, Jan 27, 2004 at 02:18:05PM +0000, David Woodhouse wrote:
> >  > All this noise on the list would be so easily avoided if 
> the list wasn't
> >  > accepting messages without a Message-ID, and wasn't 
> accepting bounces.
> >  > 
> >  > It's not hard -- it'd take _moments_ to protect the list 
> against this.
> > 
> > if you had control over the MTA, yes.
> > Sourceforget lists don't offer this power sadly.
> 
> Mailman lets you filter on certain headers though, and trap 
> messages for
> moderation. Can't you do something like looking for a Message-ID
> matching ^$ ? 
> 
> Likewise Return-Path matching <>?
> 
> -- 
> dwmw2
> 
> 
> 
> -------------------------------------------------------
> The SF.Net email is sponsored by EclipseCon 2004
> Premiere Conference on Open Tools Development and Integration
> See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
> http://www.eclipsecon.org/osdn
> _______________________________________________
> Acpi-devel mailing list
> Acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/acpi-devel
> 


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

^ permalink raw reply

* [PATCH][2.6] PCI Scan all functions
From: Jake Moilanen @ 2004-01-27 16:55 UTC (permalink / raw)
  To: Andrew Morton; +Cc: lkml

[-- Attachment #1: Type: text/plain, Size: 459 bytes --]

There are some arch, like PPC64, that need to be able to scan all the
PCI functions.  The problem comes in on a logically partitioned system
where function 0 on a PCI-PCI bridge is assigned to one partition and
say function 2 is assiged to another partition.  On the second
partition, it would appear that function 0 does not exist, but function
2 does.  If all the functions are not scanned, everything under function
2 would not be detected.

Thanks,
Jake


[-- Attachment #2: linux-2.6.1-pcibios-scan-all-fns-1.patch --]
[-- Type: text/x-patch, Size: 9602 bytes --]

diff -urpN linux-2.6.1/drivers/pci/probe.c linux-2.6.1-pcibios-scan-all-fns/drivers/pci/probe.c
--- linux-2.6.1/drivers/pci/probe.c	Fri Jan  9 00:59:47 2004
+++ linux-2.6.1-pcibios-scan-all-fns/drivers/pci/probe.c	Tue Jan 27 10:36:52 2004
@@ -7,6 +7,8 @@
 #include <linux/slab.h>
 #include <linux/module.h>
 
+#include <asm/pci.h>
+
 #undef DEBUG
 
 #ifdef DEBUG
@@ -553,7 +555,7 @@ int __devinit pci_scan_slot(struct pci_b
 
 		dev = pci_scan_device(bus, devfn);
 		pci_scan_msi_device(dev);
-		if (func == 0) {
+		if (!pcibios_scan_all_fns() && func == 0) {
 			if (!dev)
 				break;
 		} else {
diff -urpN linux-2.6.1/include/asm-alpha/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-alpha/pci.h
--- linux-2.6.1/include/asm-alpha/pci.h	Fri Jan  9 00:59:02 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-alpha/pci.h	Tue Jan 27 10:36:07 2004
@@ -51,6 +51,7 @@ struct pci_controller {
    bus numbers.  */
 
 #define pcibios_assign_all_busses()	1
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO		alpha_mv.min_io_address
 #define PCIBIOS_MIN_MEM		alpha_mv.min_mem_address
diff -urpN linux-2.6.1/include/asm-arm/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-arm/pci.h
--- linux-2.6.1/include/asm-arm/pci.h	Fri Jan  9 00:59:19 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-arm/pci.h	Tue Jan 27 10:36:07 2004
@@ -20,6 +20,8 @@
 #endif
 
 
+#define pcibios_scan_all_fns()		0
+
 static inline void pcibios_set_master(struct pci_dev *dev)
 {
 	/* No special bus mastering setup handling */
diff -urpN linux-2.6.1/include/asm-arm26/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-arm26/pci.h
--- linux-2.6.1/include/asm-arm26/pci.h	Fri Jan  9 00:59:46 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-arm26/pci.h	Tue Jan 27 10:36:07 2004
@@ -1,5 +1,6 @@
 /* Should not be needed. IDE stupidity */
 /* JMA 18.05.03 - is kinda needed, if only to tell it we don't have a PCI bus */
 
-#define PCI_DMA_BUS_IS_PHYS  0
+#define PCI_DMA_BUS_IS_PHYS  		0
+#define pcibios_scan_all_fns()		0
 
diff -urpN linux-2.6.1/include/asm-generic/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-generic/pci.h
--- linux-2.6.1/include/asm-generic/pci.h	Fri Jan  9 00:59:33 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-generic/pci.h	Tue Jan 27 10:36:07 2004
@@ -22,4 +22,6 @@ pcibios_resource_to_bus(struct pci_dev *
 	region->end = res->end;
 }
 
+#define pcibios_scan_all_fns()		0
+
 #endif
diff -urpN linux-2.6.1/include/asm-h8300/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-h8300/pci.h
--- linux-2.6.1/include/asm-h8300/pci.h	Fri Jan  9 00:59:42 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-h8300/pci.h	Tue Jan 27 10:36:07 2004
@@ -8,6 +8,7 @@
  */
 
 #define pcibios_assign_all_busses()	0
+#define pcibios_scan_all_fns()		0
 
 extern inline void pcibios_set_master(struct pci_dev *dev)
 {
diff -urpN linux-2.6.1/include/asm-i386/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-i386/pci.h
--- linux-2.6.1/include/asm-i386/pci.h	Fri Jan  9 00:59:26 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-i386/pci.h	Tue Jan 27 10:36:07 2004
@@ -15,6 +15,7 @@ extern unsigned int pcibios_assign_all_b
 #else
 #define pcibios_assign_all_busses()	0
 #endif
+#define pcibios_scan_all_fns()		0
 
 extern unsigned long pci_mem_start;
 #define PCIBIOS_MIN_IO		0x1000
diff -urpN linux-2.6.1/include/asm-ia64/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-ia64/pci.h
--- linux-2.6.1/include/asm-ia64/pci.h	Fri Jan  9 01:00:02 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-ia64/pci.h	Tue Jan 27 10:36:07 2004
@@ -16,6 +16,7 @@
  * loader.
  */
 #define pcibios_assign_all_busses()     0
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -urpN linux-2.6.1/include/asm-m68k/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-m68k/pci.h
--- linux-2.6.1/include/asm-m68k/pci.h	Fri Jan  9 00:59:33 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-m68k/pci.h	Tue Jan 27 10:36:07 2004
@@ -36,6 +36,7 @@ struct pci_bus_info
 };
 
 #define pcibios_assign_all_busses()	0
+#define pcibios_scan_all_fns()		0
 
 extern inline void pcibios_set_master(struct pci_dev *dev)
 {
diff -urpN linux-2.6.1/include/asm-m68knommu/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-m68knommu/pci.h
--- linux-2.6.1/include/asm-m68knommu/pci.h	Fri Jan  9 00:59:56 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-m68knommu/pci.h	Tue Jan 27 10:36:07 2004
@@ -11,6 +11,8 @@
 #define PCIBIOS_MIN_IO		0x100
 #define PCIBIOS_MIN_MEM		0x00010000
 
+#define pcibios_scan_all_fns()		0
+
 /*
  * Return whether the given PCI device DMA address mask can
  * be supported properly.  For example, if your device can
diff -urpN linux-2.6.1/include/asm-mips/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-mips/pci.h
--- linux-2.6.1/include/asm-mips/pci.h	Fri Jan  9 00:59:46 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-mips/pci.h	Tue Jan 27 10:36:07 2004
@@ -20,6 +20,7 @@ extern unsigned int pcibios_assign_all_b
 #else
 #define pcibios_assign_all_busses()	0
 #endif
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -urpN linux-2.6.1/include/asm-parisc/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-parisc/pci.h
--- linux-2.6.1/include/asm-parisc/pci.h	Fri Jan  9 00:59:48 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-parisc/pci.h	Tue Jan 27 10:36:07 2004
@@ -174,6 +174,7 @@ extern inline void pcibios_register_hba(
 **   to zero for legacy platforms and one for PAT platforms.
 */
 #define pcibios_assign_all_busses()     (pdc_type == PDC_TYPE_PAT)
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO          0x10
 #define PCIBIOS_MIN_MEM         0x1000 /* NBPG - but pci/setup-res.c dies */
diff -urpN linux-2.6.1/include/asm-ppc/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-ppc/pci.h
--- linux-2.6.1/include/asm-ppc/pci.h	Fri Jan  9 00:59:48 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-ppc/pci.h	Tue Jan 27 10:36:07 2004
@@ -26,6 +26,7 @@ struct pci_dev;
 extern int pci_assign_all_busses;
 
 #define pcibios_assign_all_busses()	(pci_assign_all_busses)
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
diff -urpN linux-2.6.1/include/asm-ppc64/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-ppc64/pci.h
--- linux-2.6.1/include/asm-ppc64/pci.h	Fri Jan  9 00:59:26 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-ppc64/pci.h	Tue Jan 27 10:36:07 2004
@@ -19,6 +19,12 @@
 #define PCIBIOS_MIN_IO		0x1000
 #define PCIBIOS_MIN_MEM		0x10000000
 
+/*
+ * ppc64 can have multifunction devices that do not respond to function 0. 
+ * In this case we must scan all functions.
+ */
+#define pcibios_scan_all_fns()     1
+
 static inline void pcibios_set_master(struct pci_dev *dev)
 {
 	/* No special bus mastering setup handling */
diff -urpN linux-2.6.1/include/asm-sh/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-sh/pci.h
--- linux-2.6.1/include/asm-sh/pci.h	Fri Jan  9 00:59:45 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-sh/pci.h	Tue Jan 27 10:36:07 2004
@@ -12,6 +12,7 @@
    or architectures with incomplete PCI setup by the loader */
 
 #define pcibios_assign_all_busses()	1
+#define pcibios_scan_all_fns()		0
 
 #if defined(CONFIG_CPU_SUBTYPE_ST40STB1)
 /* These are currently the correct values for the STM overdrive board. 
diff -urpN linux-2.6.1/include/asm-sparc/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-sparc/pci.h
--- linux-2.6.1/include/asm-sparc/pci.h	Fri Jan  9 00:59:48 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-sparc/pci.h	Tue Jan 27 10:36:07 2004
@@ -8,6 +8,7 @@
  * or architectures with incomplete PCI setup by the loader.
  */
 #define pcibios_assign_all_busses()	0
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO		0UL
 #define PCIBIOS_MIN_MEM		0UL
diff -urpN linux-2.6.1/include/asm-sparc64/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-sparc64/pci.h
--- linux-2.6.1/include/asm-sparc64/pci.h	Fri Jan  9 00:59:10 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-sparc64/pci.h	Tue Jan 27 10:36:07 2004
@@ -11,6 +11,7 @@
  * or architectures with incomplete PCI setup by the loader.
  */
 #define pcibios_assign_all_busses()	0
+#define pcibios_scan_all_fns()		0
 
 #define PCIBIOS_MIN_IO		0UL
 #define PCIBIOS_MIN_MEM		0UL
diff -urpN linux-2.6.1/include/asm-um/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-um/pci.h
--- linux-2.6.1/include/asm-um/pci.h	Fri Jan  9 00:59:27 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-um/pci.h	Tue Jan 27 10:36:07 2004
@@ -2,5 +2,6 @@
 #define __UM_PCI_H
 
 #define PCI_DMA_BUS_IS_PHYS     (1)
+#define pcibios_scan_all_fns()		0
 
 #endif
diff -urpN linux-2.6.1/include/asm-v850/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-v850/pci.h
--- linux-2.6.1/include/asm-v850/pci.h	Fri Jan  9 00:59:19 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-v850/pci.h	Tue Jan 27 10:36:07 2004
@@ -17,6 +17,8 @@
 /* Get any platform-dependent definitions.  */
 #include <asm/machdep.h>
 
+#define pcibios_scan_all_fns()		0
+
 /* Generic declarations.  */
 
 struct scatterlist;
diff -urpN linux-2.6.1/include/asm-x86_64/pci.h linux-2.6.1-pcibios-scan-all-fns/include/asm-x86_64/pci.h
--- linux-2.6.1/include/asm-x86_64/pci.h	Fri Jan  9 00:59:26 2004
+++ linux-2.6.1-pcibios-scan-all-fns/include/asm-x86_64/pci.h	Tue Jan 27 10:36:07 2004
@@ -17,6 +17,7 @@ extern unsigned int pcibios_assign_all_b
 #else
 #define pcibios_assign_all_busses()	0
 #endif
+#define pcibios_scan_all_fns()		0
 
 extern int no_iommu, force_iommu;
 

^ permalink raw reply

* [PATCH] fix menuconfig choice item help display
From: Bjorn Helgaas @ 2004-01-27 16:55 UTC (permalink / raw)
  To: kai, sam; +Cc: linux-kernel, kbuild-devel

This patch against 2.6.2-rc2 fixes menuconfig so it can display
help text for individual choice group config entries.

Previously it would only display the help text attached to the
"choice" item.  There was no way to display the help attached to
individual config entries inside the choice group.  Typically,
the "choice" item has no help text, and all the useful help is
attached to the individual entries, so this was a bit of a
problem.

===== scripts/kconfig/mconf.c 1.10 vs edited =====
--- 1.10/scripts/kconfig/mconf.c	Mon Jan 19 16:38:08 2004
+++ edited/scripts/kconfig/mconf.c	Tue Jan 27 09:44:30 2004
@@ -635,7 +635,9 @@
 			sym_set_tristate_value(menu->sym, yes);
 			return;
 		case 1:
-			show_help(menu);
+			if (sscanf(input_buf, "%p", &child) != 1)
+				break;
+			show_help(child);
 			break;
 		case 255:
 			return;
===== scripts/lxdialog/checklist.c 1.3 vs edited =====
--- 1.3/scripts/lxdialog/checklist.c	Tue Feb  5 00:39:14 2002
+++ edited/scripts/lxdialog/checklist.c	Tue Jan 27 09:35:44 2004
@@ -303,6 +303,9 @@
 	case 'h':
 	case '?':
 	    delwin (dialog);
+	    fprintf(stderr, "%s \"%s\"\n",
+		    items[(scroll + choice) * 3],
+		    items[(scroll + choice) * 3 + 1]);
 	    free (status);
 	    return 1;
 	case TAB:
@@ -318,7 +321,11 @@
 	case 's':
 	case ' ':
 	case '\n':
-	    if (!button) {
+	    if (button)
+		    fprintf(stderr, "%s \"%s\"\n",
+			    items[(scroll + choice) * 3],
+			    items[(scroll + choice) * 3 + 1]);
+	    else {
 		if (flag == FLAG_CHECK) {
 		    status[scroll + choice] = !status[scroll + choice];
 		    wmove (list, choice, check_x);


^ permalink raw reply

* gdb problems
From: Christopher R. Johnson @ 2004-01-27 16:48 UTC (permalink / raw)
  To: linuxppc-dev


Maybe not the right list for this, if you have a suggestion for
somewhere better let me know...

My new tool chain build is working well, except that debugging with
gdb/gdbserver is somewhat broken.  I figured out that I needed thread_db
and have that built in now and delivered to the target platform.

Problem #1: When I start host side gdb, I get the message:
warning: unable to find dynamic linker breakpoint function
GDB will be unable to debug shared library initializers
and track explicitly loaded dynamic code

I don't need to debug initializers, so I set a breakpoint at main and
continue.  Two error messages appear:
Error while mapping shared library sections:
/lib/ld.so.1: No such file or directory
Error while mapping shared library symbols:
/lib/ld.so.1: No such file or directory

The program starts and breakpoint don't work.

Problem #2:  (Maybe related?) on the target side gdbserver, after
starting things with "c" on the host side, this message appears:
gdb: error initializing thread_db library.
gdb: error initializing thread_db library.

Yes, twice.

Why is the host side looking in /lib for target libraries?  Can I
control that?  How?

Why is gdbserver on the target having trouble?  I see I have correctly
delivered the thread_db library in /lib on the target, so what gives?

Any help or guidance would be greatly appreciated.  I build my toolchain
with crosstools.

--
Christopher R. Johnson


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* Re: [patch] remove null-ifiers
From: Yury V. Umanets @ 2004-01-27 16:44 UTC (permalink / raw)
  To: Matthew Wilcox
  Cc: Jes Sorensen, acpi-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f,
	len.brown-ral2JQCrhuEAvxtiuMwx3w
In-Reply-To: <20040127154314.GY11844-+pPCBgu9SkPzIGdyhVEDUDl5KyyQGfY2kSSpQ9I8OhVaa/9Udqfwiw@public.gmane.org>

On Tue, 2004-01-27 at 18:43, Matthew Wilcox wrote:
> On Tue, Jan 27, 2004 at 04:09:55PM +0100, Karol Kozimor wrote:
> > > -static uid_t asus_uid = 0;
> > > -static gid_t asus_gid = 0;
> > > +static uid_t asus_uid;
> > > +static gid_t asus_gid;
> > 
> > We certainly *don't* want to do that, last time I checked C did not
> > actually guarantee to zero out uninitialized variables -- unless it's
> > different in the kernelspace. Are you sure pointers are initialized as
> > NULLs?
> 
> Looks like you checked the wrong standard then.  Global variables are
> guaranteed to be zeroed, stack variables (ie function-local) have the
> behaviour you described.  Jes' patch is correct.

Global uninitialized variables should be located in BSS section of ELF. 

Then somebody should initialize BSS at the start of a program. In user
space this is done by crt.* small objects written in assembler and
built-in to each application by gcc.

In kernel space this should be done by kernel itself. And I guess, this
is done. So, I don't see any reasons to initialize global variables and
thus to make kernel data segment bigger...


-- 
umka



-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn

^ permalink raw reply

* Re: [PATCH] ide-dma.c, ide.c, ide.h, kernel 2.4.24
From: Glenn Wurster @ 2004-01-27 16:41 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz
  Cc: Glenn Wurster, Alan Cox, torvalds, linux-kernel, andre
In-Reply-To: <200401271614.40542.bzolnier@elka.pw.edu.pl>


> Doh.  I overlooked one place.
> IMO this check needs to be added only to two places.

True, I added the check three times to emphasise the three different
calls which could potentially OOPS (at least upon initial
observation).  It could be optimized into 2 checks.

> Did you test this patch?

Yes.

> I've seen this and decided that it is not needed.
> 
> If we try to program drives to DMA on non-DMA host
> something is going wrong and it is better to just OOPS.

This makes sense.  Did you want to update the patch for those proposed
changes (You're more familiar with the code than I - I'm reluctant to
play too much with code unless I understand what it is doing)?  I'd be
willing to test an updated patch.

> I suspect that this is caused by unfinished handling of simplex
> devices in setup-pci.c (simplex host - one DMA engine but two
> channels).

I'm really not familiar with the complexities behind DMA
programming, especially when it comes to simplex devices so I'm
probably not in much of a position to finish up handling of simplex
devices.

Glenn.

^ permalink raw reply

* Re: [Bluez-devel] Windows Port
From: Marcel Holtmann @ 2004-01-27 16:38 UTC (permalink / raw)
  To: acr; +Cc: BlueZ Mailing List
In-Reply-To: <48760.80.63.28.114.1075219113.squirrel@acroberts.com>

Hi Antony,

> I've just been looking at the code (from 2.4 - I'm running RH9). As far as
> I can see L2CAP and RFCOMM are connected by a socket interface, and L2CAP
> and the HCI layer are connected by a callback interface, yes?
> 
> After a very cursory investigation, I don't think it's a lot of work to
> create an abstraction layer so that Windows can provide the same APIs that
> BlueZ is using. In fact Microsofts BT implementation also uses a
> socket-based approach (unfortunately, because MS don't want us innovating
> in Bluetooth, everything other than RFCOMM is locked down).
> 
> Of course, the hci_ API would have to be re-written to accomodate the new
> driver (probably need to use sockets there as well), but I don't see why
> L2CAP and RFCOMM couldn't communicate in the same way on Windows. I'd
> probably move them up into user space as services - this of course means
> you have a messy route back into kernel mode for Virtual Serial port
> functions, but still, I'd say it's doable.
> 
> I would draw the line at Virtual Serial Port and BNEP, and let Windows
> have it's own user services (not the same as the gnome stuff for BlueZ).
> 
> What do you think? Am I right in that we are basically talking about
> sockets for L2CAP and RFCOMM?

I don't believe that it is possible to port BlueZ to the Windows
platform, but I also don't wanna keep you from trying it. Personally I
think it is easier to start from scratch and then offer the same
interfaces as BlueZ does for Linux.

Regards

Marcel




-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Bluez-devel mailing list
Bluez-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bluez-devel

^ permalink raw reply

* Re: starting an application
From: Greg KH @ 2004-01-27 16:36 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <Law10-F86BJ8QiIWMzR00005c68@hotmail.com>

On Mon, Jan 26, 2004 at 12:52:42PM -0600, Sanjay lal wrote:
> Hello,
> i need to start an application that is on a USB device, as and when it is 
> plugged in . This application has a curses based User Interface.
> I am able to start the application ,using hotplug, but anything started by 
> hotplug seems to run in the background. And this would make the curser UI, 
> not visible.

It's a problem as hotplug runs from the kernel directly, with no stdin
or stdout.  I don't think you will be able to do this easily.

Sorry,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* Re: udev dri directory rule
From: Greg KH @ 2004-01-27 16:35 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <20040127021658.36941.qmail@web14902.mail.yahoo.com>

On Mon, Jan 26, 2004 at 06:16:58PM -0800, Jon Smirl wrote:
> Would this line:
> KERNEL="card*", NAME="dri/card%n"
> be better written as:
> KERNEL="card*", NAME="dri/%k"

It doesn't really matter, both work the same here :)

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* Re: porting sorcerer to udev
From: Greg KH @ 2004-01-27 16:35 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <401633EA.4000102@laposte.net>

On Tue, Jan 27, 2004 at 10:48:26AM +0100, MALET JL wrote:
> hello,
> I'm one of the linux sorcerer maintainer and I'm trying to switch 
> sorcerer to udev (from devfs)
> the "spells" (compile/install scripts) are done and everything install fine
> hotplug scripts seems to work correctly at least for usb (some strange 
> error on pci only with 2.6 kernels, some modules aren't loaded but I 
> haven't investigateted further) : my usb mouse/adaptaters modules are 
> loaded at boot time....
> so this means : 1) pci hosts are detected 2) usb OHCI generate the event 
> (detection of usbmouse) and hotplug loads the corrects modules :)
> BUT :( udev don't work
> running the test scripts work correctly (it's awfully long but at least 
> this create some entries) after i mounted sysfs into /sys (previous 
> mount point was /sysfs but udev don't work with it)
> so I don't understand.....

What are the error messages?

> I readed into the docs and found that udev/hotplug is now 
> udev/namedev/hotplug/libsysfs but I can't find namedev stuff can it 
> comes from that?

No, udev contains "namedev" and "libsysfs".  They are all built into one
udev binary.

> the link of udev into hotplug.d is correct and have the rights modes
> if someone can help.....

Build udev with DEBUG=true and USE_LOG=true and show us what the debug
logs say when you run udev.  

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* Re: GPL license and linux kernel modifications
From: Kevin P. Fleming @ 2004-01-27 16:33 UTC (permalink / raw)
  To: linux-kernel
In-Reply-To: <E1AlW2F-000N9k-00.bansh21-mail-ru@f13.mail.ru>

Bansh wrote:

> special exception, the source code distributed need not include
> anything that is normally distributed (in either source or binary
> form) with the major components (compiler, kernel, and so on) of the
> operating system on which the executable runs, unless that component
> itself accompanies the executable.
> ----------- cut COPYING -----------
> 
> It gives the possibility to not distribute compiler and other preprocessing tools.
> It looks like one can make a preprocessor or even one's own compiler (with one's syntax) which will be used for kernel building. But it's not required to distribute this compiler. So I can distribute linux kernel source code modified this way but no one will be able to build it. Is it ok?

Only if those "compiler and other preprocessing tools" are normally 
distributed with the O/S the executable runs on. If you create your own 
compiler, and it's not "normally distributed", then you can't publish 
source code in that language under the GPL without making the compiler 
available as well.


^ permalink raw reply

* Re: MO: opening for write in cdrom.c
From: Jens Axboe @ 2004-01-27 16:33 UTC (permalink / raw)
  To: Pascal Schmidt; +Cc: linux-kernel
In-Reply-To: <Pine.LNX.4.44.0401271406070.881-100000@neptune.local>

On Tue, Jan 27 2004, Pascal Schmidt wrote:
> > Hmm, looks a bit strange. You want write protect to be set _if_
> > detection works, not otherwise. If it fails, just assume that you can
> > write to the drive and let the normal drive rejection work fail those
> > (maybe even catch them and write protect then).
> 
> Before I had this worked out, I accidentally tried fscking a
> write-protected disc. Yes, it errored out at the end of the fsck, but
> the error messages are quite unintuitive. Lot's of I/O error in the
> kernel log and an error=0x70 from the drive. I sure didn't realize
> at first what the problem really was.

I'm surprised the sense messages don't show that it's a write to a write
protected disc (xx/27/zz, where xx == 0x07 or 0x05). However, it's even
more annoying to _not_ be able to write to a media because the kernel
thinks it knows better. In your fsck case you sort of get what you ask
for, by shooting yourself in the foot :)

> > Seeing as the method is
> > unreliable, we cannot solely rely on that.
> 
> I've not seen all three variants fail, yet. I was following sd.c's
> example, that also sets write protect by default if it cannot get
> info from the drive.
> 
> It's fine with me either way. Do you want me to resend with the
> default fallback changed?

Yes please.

> Oh, BTW, while I have your attention ;), have you looked at my
> latest variable blocksize support patch for ide-cd? I've tried to
> incorporate yours and Bart's suggestions.
> 
> Here it is again in case you missed it in the thread.
> 
> 
> --- linux-2.6.2-rc1/drivers/ide/ide-cd.c.orig	Sat Jan 24 01:24:03 2004
> +++ linux-2.6.2-rc1/drivers/ide/ide-cd.c	Sat Jan 24 01:39:40 2004
> @@ -294,10 +294,12 @@
>   * 4.60  Dec 17, 2003	- Add mt rainier support
>   *			- Bump timeout for packet commands, matches sr
>   *			- Odd stuff
> + * 4.61  Jan 22, 2004	- support hardware sector sizes other than 2kB,
> + *			  Pascal Schmidt <der.eremit@email.de>
>   *
>   *************************************************************************/
>   
> -#define IDECD_VERSION "4.60"
> +#define IDECD_VERSION "4.61"
>  
>  #include <linux/config.h>
>  #include <linux/module.h>
> @@ -1211,6 +1213,7 @@ static int cdrom_read_from_buffer (ide_d
>  {
>  	struct cdrom_info *info = drive->driver_data;
>  	struct request *rq = HWGROUP(drive)->rq;
> +	unsigned short sectors_per_frame = drive->queue->hardsect_size >> 9;

Nitpick: sectors_per_frame = queue_hardsect_size(q) >> 9;

That's about, the rest looks fine.

-- 
Jens Axboe


^ permalink raw reply

* Re: porting sorcerer to udev
From: Greg KH @ 2004-01-27 16:33 UTC (permalink / raw)
  To: linux-hotplug
In-Reply-To: <401633EA.4000102@laposte.net>

On Tue, Jan 27, 2004 at 05:43:33PM +0500, Ananth N Mavinakayanahalli wrote:
> On Tue, Jan 27, 2004 at 10:48:26AM +0100, MALET JL wrote:
> > BUT :( udev don't work
> > running the test scripts work correctly (it's awfully long but at least 
> > this create some entries) after i mounted sysfs into /sys (previous 
> > mount point was /sysfs but udev don't work with it)
> > so I don't understand.....
> 
> Hmm.. libsysfs should pick up the sysfs mount point irrespective of
> whether it is mounted on /sys or otherwise. Can you please check by
> enabling logging in libsysfs by setting DEBUG to 1 in sysfs.h and see
> where it is erroring out?

If udev is built with klibc it will just assume that sysfs is mounted at
/sys.

Is there any reason you are not mounting sysfs at /sys?  That's the
current convention.

thanks,

greg k-h


-------------------------------------------------------
The SF.Net email is sponsored by EclipseCon 2004
Premiere Conference on Open Tools Development and Integration
See the breadth of Eclipse activity. February 3-5 in Anaheim, CA.
http://www.eclipsecon.org/osdn
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* Re: trafic info
From: Juan Hernandez @ 2004-01-27 16:33 UTC (permalink / raw)
  To: Lista de netfilter
In-Reply-To: <1169375166.20040127185956@internetplustravel.ru>

Pal, go to www.freshmeat.net and download iptraf... great tool for
monitoring network connections

Juan

On Tue, 2004-01-27 at 11:59, Oleg Savostyanov wrote:
> Hello netfilter,
> 
> I am using my LinuxBox as a NAT device for my LAN.
> Debian Woody 2.4.23
> I suspect one of my (or not one) computers infected by virus
> And generating outgoing trafic.
> Is there any way without installing packages to view from my linuxbox
> established connects, any info about
> transferred bytes during this connect, etc..?
> Or maybe someone can suggest good program for that.
> 
> Thanks in advance.
> 
> 
> 
> 
> Oleg                          mailto:savostyanov@internetplustravel.ru
> 
> 



^ permalink raw reply

* Re: RFC: Trailing blanks in source files
From: Bas Mevissen @ 2004-01-27 16:30 UTC (permalink / raw)
  Cc: rmps, linux-kernel, yoshfuji
In-Reply-To: <20040128.011537.81631272.yoshfuji@linux-ipv6.org>

YOSHIFUJI Hideaki / ???? wrote:
> In article <Pine.LNX.4.58.0401271544120.27260@joel.ist.utl.pt> (at Tue, 27 Jan 2004 15:44:56 +0000 (WET)), Rui Saraiva <rmps@joel.ist.utl.pt> says:
> 
> 
>>	It seems that many files [1] in the Linux source have lines with
>>trailing blank (space and tab) characters and some even have formfeed
>>characters. Obviously these blank characters aren't necessary.
> 
> 
> I do not like to change this if it is done blindly.
> 

Agree. But if you compile a allconfigyes kernel before and after and 
they appear to be binary equal, we know we are pretty safe :-)


Regards,

Bas.


^ permalink raw reply

* Re: 2.4.22-bk30 and C trigraphs bugs
From: Xose Vazquez Perez @ 2004-01-27 16:21 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: linux-kernel
In-Reply-To: <20040119153814.5ebc3a87.rddunlap@osdl.org>

Randy.Dunlap wrote:

> On Thu, 09 Oct 2003 01:44:31 +0200 Xose Vazquez Perez <xose@wanadoo.es> wrote:
> 
> | hi,
> | 
> | There are some mistakes with C trigraphs:
> | 
> | arch/m68k/atari/stram.c:                        PRINT_PROC( "??)\n" );
> | arch/sparc/kernel/traps.c:              die_if_kernel("Penguin instruction from Penguin mode??!?!", regs);
> | drivers/atm/idt77252.c:         printk("%s: PCI_COMMAND: %04x (???)\n",
> | drivers/acorn/scsi/acornscsi.c:    "??-out",                    /* 1C */
> | drivers/acorn/scsi/acornscsi.c:    "??-in",                     /* 1D */
> | drivers/block/acsi.c:   { 0x00, "No error (??)" },
> | drivers/block/acsi.c:   { 0x00, "No error (??)" },
> | drivers/media/video/saa7110.c:          DEBUG(printk(KERN_INFO "unknown saa7110_command??(%d)\n",cmd));
> | drivers/mtd/maps/sun_uflash.c:          name:           "SUNW,???-????",
> | drivers/scsi/ppa.c:     printk("ppa: parity error (???)\n");
> | drivers/scsi/ppa.c:     printk("ppa: bad interrupt (???)\n");
> | drivers/scsi/imm.c:     printk("imm: parity error (???)\n");
> | drivers/scsi/imm.c:     printk("imm: bad interrupt (???)\n");
> | net/rose/af_rose.c:                     callsign = "??????-?";
> | 
> | fixes are trivial.
> | 
> | Is 2.6.0-pre free of them  :-?
> 
> Of course not.  I grepped over 100 of them in 2.6.1.
> 
> Are they a problem?

Visually yes, they hurt to the sight ;-)

But unless somebody uses -std or -ansi, by default GCC
ignores trigraphs.

-- 
Software is like sex, it's better when it's bug free.



^ permalink raw reply

* Re: [patch] Re: Kernels > 2.6.1-mm3 do not boot. - SOLVED
From: Andi Kleen @ 2004-01-27 16:26 UTC (permalink / raw)
  To: Eric; +Cc: Andrew Morton, stoffel, ak, Valdis.Kletnieks, bunk, cova,
	linux-kernel
In-Reply-To: <200401270037.43676.eric@cisu.net>

On Tue, Jan 27, 2004 at 12:37:43AM -0600, Eric wrote:
> On Monday 26 January 2004 23:50, Andrew Morton wrote:
> > Eric <eric@cisu.net> wrote:
> > > YES. I finally have a working 2.6.2-rc1-mm3 booted kernel.
> > >  Lets review folks---
> > >  	reverted -funit-at-a-time
> > >  	patched test_wp_bit so exception tables are sorted sooner
> > >  	reverted md-partition patch
> >
> > The latter two are understood, but the `-funit-at-a-time' problem is not.
> >
> > Can you plesae confirm that restoring only -funit-at-a-time again produces
> > a crashy kernel?  And that you are using a flavour of gcc-3.3?  If so, I
> > guess we'll need to only enable it for gcc-3.4 and later.
> >
> Yes, confirmed. My  version of gcc, I just sent you adding the 
> -funit-at-a-time hung after uncompressing the kernel. I booted a secondary 
> kernel, recompiled without it and all was fine again. Confirmed non-boot for 
> 2.6.2-rc1-mm3 but without a doubt for all kernels previous where 
> -funit-at-a-time is active in the makefile.

Ok thanks for the confimration. I will try to reproduce this with the 
SuSE 8.2 compiler and track it down.

-Andi

^ permalink raw reply

* GPL license and linux kernel modifications
From: "Bansh"  @ 2004-01-27 16:25 UTC (permalink / raw)
  To: linux-kernel

Hello!

I've got a question, which I can't resolve myself about linux kernel binary code. The problem is GPL license which tells us that:

----------- cut COPYING -----------
The source code for a work means the preferred form of the work for
making modifications to it.  For an executable work, complete source
code means all the source code for all modules it contains, plus any
associated interface definition files, plus the scripts used to
control compilation and installation of the executable.  However, as a
special exception, the source code distributed need not include
anything that is normally distributed (in either source or binary
form) with the major components (compiler, kernel, and so on) of the
operating system on which the executable runs, unless that component
itself accompanies the executable.
----------- cut COPYING -----------

It gives the possibility to not distribute compiler and other preprocessing tools.
It looks like one can make a preprocessor or even one's own compiler (with one's syntax) which will be used for kernel building. But it's not required to distribute this compiler. So I can distribute linux kernel source code modified this way but no one will be able to build it. Is it ok?

Such compiler/preprocessor can be really very tricky and can hide the modifications very much, thus allowing to hide proprietary know-how.

Bansh

^ permalink raw reply

* Re: linuxppc trees / BK help
From: Andreas Schwab @ 2004-01-27 16:23 UTC (permalink / raw)
  To: Christian Kujau; +Cc: linuxppc-dev
In-Reply-To: <40168C3E.7010903@g-house.de>


Christian Kujau <evil@g-house.de> writes:

> after passing the consistency check, a sourcetree shows up  but
> filenames are different from normal:
>
> evil@sheep:/data/MP3/scratch/kernel$ ls linuxppc-2.5-benh-BK/
> BitKeeper  Documentation  SCCS  arch  crypto  drivers  fs  include  init
> ~ ipc  kernel  lib  mm  net  scripts  security  sound  usr
> evil@sheep:/data/MP3/scratch/kernel$
>
> - --> there are no files in the directory, only dirs.

$ bk -r get

Andreas.

--
Andreas Schwab, SuSE Labs, schwab@suse.de
SuSE Linux AG, Maxfeldstraße 5, 90409 Nürnberg, Germany
Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

^ permalink raw reply

* MPC8xx SCC for sync. HDLC on 2.4 kernel
From: Jos Beck @ 2004-01-27 16:23 UTC (permalink / raw)
  To: linuxppc-embedded


I am trying to build a synchronous HDLC driver for the SCC of the MPC850/860
under linux kernel 2.4.22

I have got one working on a 2.2.5 kernel and one buggy, async only, for the 2.4
kernels.
What would be the best approach: porting the 2.2.5 driver to the 2.4.x kernel or
digging into the driver (ehdlc.c by Rodolfo Giometti based on Dan Malek's
enet.c) to make it work for sync HDLC at high speeds?

Or an alternative?


Best regards,

Jos Beck


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.