* Gianfar skb panic when bonding a VLAN interface
From: Demke Torsten-atd012 @ 2007-10-30 17:28 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I tried to ping over a bonded VLAN tagged interface.
(e.g -> ifenslave bond0 eth3.24)
This fails with following output:
root@myBoard:/root> ping 192.168.24.101
PING 192.168.24.skb_under_panic: text:c01bbdf8 len:50 put:8
head:dd27a3a0 data:dd27a39a tail:dd27a3cc end:dd27a3e0 dev:eth3
Oops: Exception in kernel mode, sig: 5 [#1]
NIP: C01E9110 LR: C01E9110 SP: C03479F0 REGS: c0347940 TRAP: 0700
Tainted: PF =20
MSR: 00021000 EE: 0 PR: 0 FP: 0 ME: 1 IR/DR: 00
TASK =3D c03031a0[0] 'swapper' THREAD: c0346000
Last syscall: 120=20
GPR00: C01E9110 C03479F0 C03031A0 00000072 00002D03 FFFFFFFF 00000030
00003FFF=20
GPR08: C037D0AC C0340000 FFFFFFFF 00000000 65F51C00 60000000 0FFE3900
C0347A7C=20
GPR16: DFC1FD60 C0347DD0 C0B94800 0FFF3D0C C0347A80 00000000 007FD890
00000000=20
GPR24: 00000000 C0A81865 C0A81805 00000000 C0B94800 DFC1FD60 C0B94A40
DF10C128=20
NIP [c01e9110] skb_under_panic+0x50/0x64
LR [c01e9110] skb_under_panic+0x50/0x64
Call trace:
[c01bbe0c] gfar_add_fcb+0x7c/0xb4
[c01bbfc0] gfar_start_xmit+0x160/0x268
[c01ffffc] qdisc_restart+0x100/0x1fc
[c01f04c4] dev_queue_xmit+0xc88/0xde0
[c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0
[c01f054c] dev_queue_xmit+0xd10/0xde0
[c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4
[c01b4464] bond_xmit_roundrobin+0x94/0x108
[c01f054c] dev_queue_xmit+0xd10/0xde0
[c022f6cc] arp_xmit+0x5c/0x6c
[c022f704] arp_send+0x28/0x38
[c022ef48] arp_solicit+0x1a0/0x1c0
[c01f81b0] neigh_timer_handler+0x294/0x31c
[c0043310] run_timer_softirq+0xa7c/0xaec
[c0039b68] __do_softirq+0xabc/0x15a0
101 (192.168.24.Kernel panic - not syncing: Aiee, killing interrupt
handler!
101) 56(84) byte s of data.
Call trace:
[c0008258] dump_stack+0x18/0x28
[c002fa50] panic+0xa8/0x190
[c0033690] do_exit+0x3c/0xdec
[c0002fb4] _exception+0x0/0x1558
[c0002ff0] _exception+0x3c/0x1558
[c0004d70] ProgramCheckException+0x11c/0x1c4
[c00029ac] ret_from_except_full+0x0/0x4c
[c01e9110] skb_under_panic+0x50/0x64
[c01bbe0c] gfar_add_fcb+0x7c/0xb4
[c01bbfc0] gfar_start_xmit+0x160/0x268
[c01ffffc] qdisc_restart+0x100/0x1fc
[c01f04c4] dev_queue_xmit+0xc88/0xde0
[c02a9684] vlan_dev_hwaccel_hard_start_xmit+0x9c/0xb0
[c01f054c] dev_queue_xmit+0xd10/0xde0
[c01afaa8] bond_dev_queue_xmit+0x2a8/0x2c4
Rebooting in 180 seconds..
It seems that the skb headroom is to small. How can I solve this?
I could insert skb_realloc_headroom() call, but where it's the best
place then?
What about alignement?
Regards,
Torsten
^ permalink raw reply
* Continued serial headaches
From: Alan Bennett @ 2007-10-30 17:42 UTC (permalink / raw)
To: Scott Wood, linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 2085 bytes --]
Well, now that I've got IRQs requestable, I'm back to battling SCC1 / SCC4
initialization,
I've verified the iop structures, and things look set-up correctly.
/* SCC1 */
{2, 14, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{2, 15, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
{3, 29, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 30, CPM_PIN_OUTPUT | CPM_PIN_SECONDARY},
{3, 31, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
/* SCC4 */
{3, 21, CPM_PIN_OUTPUT | CPM_PIN_PRIMARY},
{3, 22, CPM_PIN_INPUT | CPM_PIN_PRIMARY},
I've also verified that upon first use (echo "test" > /dev/ttyCPM[12] the
brgs are configured)
SCC1
cpm_uart_startup:417
CPM uart[1]:startup on IRQ: 40 - request returned 0
cpm_uart_startup:432 CPM uart[1] is scc
CPM uart[1]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119f0:00010140
CPM uart[1]:shutdown
SCC4
cpm_uart_startup:417
CPM uart[2]:startup on IRQ: 43 - request returned 0
cpm_uart_startup:432 CPM uart[2] is scc
CPM uart[2]:set_termios
cpm_setbrg [cpm2_common.c:106] e00119fc:00010140
CPM uart[2]:shutdown
CPM uart[2]:initbd
However, SCC1 continues to get locked.
Am I missing something in the PRAM areas?
SMC1 (ttyCPM0...)
e0008000 : 00c000e0 30300020 00000000 eefe3e7a
e0008010 : 00c07331 11b6b05f 30440000 07f4d082
e0008020 : 00e00003 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 00010000
e0008040 : 00000000 0000fc9d 00000000 d08a0000
e0008050 : 80008000 80008000 80008000 80008000
SCC1
e0008000 : 00c000e0 30300020 00000000 eefe3e7a
e0008010 : 00c07331 11b6b05f 30440000 07f4d082
e0008020 : 00e00003 746562ec d98ceffd 0dec67e3
e0008030 : df7b2db5 5f0bf2dc 00205ce8 00010000
e0008040 : 00000000 0000fc9d 00000000 d08a0000
e0008050 : 80008000 80008000 80008000 80008000
SCC4
e0008300 : 01000120 30300020 30401000 07f4e001
e0008310 : 0100001f 993fb24d 30004000 07f4e0a2
e0008320 : 01300000 0d0a8379 fedddfdc 94a967eb
e0008330 : 5d2b06bd 4708b3ce 0020001f 00010000
e0008340 : 00000000 00002804 00000000 e8a60000
e0008350 : 80008000 80008000 80008000 80008000
-Alan
[-- Attachment #2: Type: text/html, Size: 2611 bytes --]
^ permalink raw reply
* Socket I/O in Kernel
From: Dave Cogley @ 2007-10-30 17:46 UTC (permalink / raw)
To: linuxppc-embedded
[-- Attachment #1.1: Type: text/plain, Size: 774 bytes --]
Hello,
I am trying to setup a socket endpoint for network I/O (UDP) into my driver
and I am having some trouble. I am seemingly able to create and bind a UDP
socket using sock_create_kern without any failure. The problem comes when I
try to send data over the datagram it always fails with EINVAL. Is
kernel_sendmsg a valid routine for sending data over unconnected datagrams?
Should I be using kernel_sendpage? Am I initializing the datagram
correctly? Is there any working example of how to use UDB sockets at the
kernel level? I have attached the driver source if you wish to see the
initialization and write routines. Thank you for your time.
Thanks,
Dave Cogley
Software Engineer
Ultra Stereo Labs, Inc.
(805) 549-0161
mailto:dcogley@uslinc.com
[-- Attachment #1.2: Type: text/html, Size: 3297 bytes --]
[-- Attachment #2: banjodecoder.c --]
[-- Type: text/plain, Size: 14931 bytes --]
/*
* banjodecoder.c
* USL, Inc.
*
* This file contains the driver for the Banjo image and audio decoders.
*
* Revision 0.1 07/18/2007 dcogley
* - Initial Creation
*
*/
#include <linux/module.h>
#include <linux/moduleparam.h>
#include <linux/init.h>
#include <linux/kernel.h>
#include <linux/slab.h>
#include <linux/fs.h>
#include <linux/errno.h>
#include <linux/types.h>
#include <linux/proc_fs.h>
#include <linux/interrupt.h>
#include <linux/delay.h>
#include <linux/ctype.h>
#include <linux/net.h>
#include <linux/socket.h>
#include <linux/in.h>
#include <linux/udp.h>
#include <asm/io.h>
#include <asm/uaccess.h>
#include "banjodecoder.h"
#define DRIVER_VERSION "0.1"
#define DRIVER_NAME "banjodecoder"
MODULE_DESCRIPTION("USL, Inc. Image Decoder driver v" DRIVER_VERSION);
MODULE_LICENSE("GPL");
MODULE_AUTHOR("Dave Cogley");
int banjo_major = BANJO_MAJOR;
module_param(banjo_major, int, 0);
struct banjo_dev* banjo_device = 0;
void __iomem* banjo_regmap = 0;
void __iomem* gpio1_or = 0;
// the data port socket descriptor
static struct udp_sock* sockData = 0;
struct sockaddr_in sinDataAddr = { 0 };
// the control port socket descriptor
static struct udp_sock* sockControl = 0;
struct sockaddr_in sinControlAddr = { 0 };
// the transmit buffer
volatile static char sockBuf[MAX_TX_PACKET + PKTALIGN];
volatile static char* sockTxBuf;
extern int banjosock_init(const char* serverip);
extern void banjosock_cleanup(void);
extern int banjosock_decueFeature(void);
extern int banjosock_cueFeature(const char* feature);
extern int banjosock_requestFrame(int frame);
/* Macros for accessing the indirect EBC registers */
void mtebc(u32 reg, u32 data)
{
mtdcr(ebccfga, reg);
mtdcr(ebccfgd, data);
}
u32 mfebc(u32 reg)
{
mtdcr(ebccfga, reg);
return mfdcr(ebccfgd);
}
void enable_per_ready(int enable)
{
u32 pb1ap;
// set peripheral 1 access permissions to disable "peripheral ready"
pb1ap = mfebc(PB1AP);
if (enable)
pb1ap |= PB1AP_ENABLE;
else
pb1ap &= ~PB1AP_ENABLE;
mtebc(PB1AP, pb1ap);
}
static void setup_dma_buffer(void)
{
// setup count and control register
mtdcr(DMA2P40_CTC0, DMA_CONTROLTC0);
// 64b source address
mtdcr(DMA2P40_SAH0, 0x00000000); // must be zero
mtdcr(DMA2P40_SAL0, DMABUFFERBASE);
// destination address is fixed to the banjo decoder media address
// the destination address really does not matter to the FPGA but
// because of address alignment problems we want to start at the
// base address
mtdcr(DMA2P40_DAH0, 0x00000001); // destination is addressable on the EBC
mtdcr(DMA2P40_DAL0, BANJO_DECODER_BASE);
}
irqreturn_t dma_status_int(int irq, void *dev_id, struct pt_regs *regs)
{
u32 status;
// get and clear the DMA status
status = mfdcr(DMA2P40_SR);
mtdcr(DMA2P40_SR, status);
// status is TC expire, EOT request (never happens) or error occured
if (status & DMA0_TC_REACHED ||
status & DMA0_EOT_REQ ||
status & DMA0_ERROR)
{
if (status & DMA0_ERROR)
{
// frame xfer asseterted a DMA error
banjo_device->frames_dma_error++;
}
else
{
// frame successfully transfered
banjo_device->frames_sent++;
}
// drive GPIO48 (EOTn) high to indicate end of transfer
writel(EOTN_DRIVE_HIGH, gpio1_or);
// release the DMA buffer
banjo_device->dma.flags = 0;
}
return IRQ_HANDLED;
}
irqreturn_t frame_req_int(int irq, void *dev_id, struct pt_regs *regs)
{
u32 control;
// increment frames requested
banjo_device->frames_request++;
// is buffer available?
if (!(banjo_device->dma.flags & BANJO_DMA_FLAG_DMAREADY))
{
banjo_device->frames_not_ready++;
return IRQ_HANDLED; // frame request made and buffer was not ready!
}
setup_dma_buffer();
// drive GPIO48 (EOTn) low
writel(EOTN_DRIVE_LOW, gpio1_or);
// enable the DMA channel
// the DMA channel is now armed and will begin the transfer immediatly
// to the configured DMA addresses
control = mfdcr(DMA2P40_CR0);
control |= DMA_ENABLE_CHANNEL;
mtdcr(DMA2P40_CR0, control);
return IRQ_HANDLED;
}
int banjo_open(struct inode* inode, struct file* filp)
{
return 0;
}
int banjo_release(struct inode* inode, struct file* filp)
{
return 0;
}
int banjo_ioctl(struct inode* inode, struct file* filp, unsigned int cmd, unsigned long arg)
{
int ret = 0;
u32 status;
u32 frame;
switch (cmd)
{
// reset the banjo decoder
case BANJO_IOCDECODERRESET:
writel(0xffffffff, banjo_regmap + BANJO_RESET_ADDR);
writel(0x00000000, banjo_regmap + BANJO_RESET_ADDR);
mdelay(BANJO_RESET_DELAY);
break;
case BANJO_IOCDECODERSTATUS:
// peripheral ready must be enabled while reading resigeter map
enable_per_ready(1);
status = readl(banjo_regmap + BANJO_STATUS_ADDR);
ret = __put_user(status, (long __user*)arg);
enable_per_ready(0);
break;
case BANJO_IOCENABLESTREAM:
// enable the frame request interrupts
writel(0xffffffff, banjo_regmap + BANJO_STATUS_ADDR);
break;
case BANJO_IOCCONNECTSERVER:
// initialize network layer
// banjosock_init("128.0.0.1\0");
banjosock_init("192.168.1.49\0");
break;
case BANJO_IOCDISCONNECTSERVER:
banjosock_cleanup();
break;
case BANJO_IOCCUEFEATURE:
// decue current feature
banjosock_cueFeature("urn:uuid:a36c264b-2926-fc46-8e10-93e24a75d1c0");
break;
case BANJO_IOCDECUEFEATURE:
// decue current feature
banjosock_decueFeature();
break;
case BANJO_IOCREQUESTFRAME:
// get the frame we want to request
__get_user(frame, (long __user*)arg);
// make a frame request and pass the current DMA frame buffer
banjosock_requestFrame(frame);
banjo_device->dma.flags |= BANJO_DMA_FLAG_DMAREADY;
break;
}
return ret;
}
static inline int do_sendto(struct socket* sock, struct kvec* vec, int count,
int len, unsigned flags, struct sockaddr_in* sin)
{
struct msghdr msg;
msg.msg_name = sin;
msg.msg_namelen = sizeof (struct sockaddr_in);
msg.msg_flags = flags;
return kernel_sendmsg(sock, &msg, vec, count, len);
}
static int _sendto(struct socket* sock, const void *buf, int len,
struct sockaddr_in* sin)
{
struct kvec vec;
vec.iov_base = (void*)buf;
vec.iov_len = len;
return do_sendto(sock, &vec, 1, len, 0, sin);
}
static int _recv(struct socket *sock, void* buf, int size, unsigned flags)
{
struct msghdr msg = { NULL, };
struct kvec iov = { buf, size };
return kernel_recvmsg(sock, &msg, &iov, 1, size, flags);
}
int banjosock_inetaddr(const char* cp, u32* dst)
{
int value;
int digit;
int i;
char temp;
char bytes[4] = { 0 };
char *end = bytes;
static const int addr_class_max[4] =
{ 0xffffffff, 0xffffff, 0xffff, 0xff };
temp = *cp;
while (1)
{
if (!isdigit(temp))
return 0;
value = 0;
digit = 0;
for (;;)
{
if (isascii(temp) && isdigit(temp))
{
value = (value * 10) + temp - '0';
temp = *++cp;
digit = 1;
} else
break;
}
if (temp == '.')
{
if ((end > bytes + 2) || (value > 255))
return 0;
*end++ = value;
temp = *++cp;
}
else
break;
}
if (value > addr_class_max[end - bytes])
return 0;
*((u32*)dst) = *((u32*)bytes) | htonl(value);
return 1; /* success */
}
// initialize our socket i/o
int banjosock_init(const char* serverip)
{
// setup data and control addresses
sinDataAddr.sin_family = AF_INET;
sinDataAddr.sin_port = htons(DATAPORT);
banjosock_inetaddr(serverip, &sinDataAddr.sin_addr.s_addr);
sinControlAddr.sin_family = AF_INET;
sinControlAddr.sin_port = htons(CONTROLPORT);
banjosock_inetaddr(serverip, &sinControlAddr.sin_addr.s_addr);
// allocate a data stream descriptor
if (sock_create_kern(PF_INET, SOCK_DGRAM, IPPROTO_UDP, &sockData) < 0 ||
!sockData ||
kernel_connect(sockData, sinDataAddr, sizeof (sinDataAddr)) < 0)
{
printk(KERN_ERR "banjosock_init: problem creating / binding DATA socket\n");
return -1;
}
// allocate a control port descriptor
if (sock_create_kern(AF_INET, SOCK_DGRAM, IPPROTO_UDP, &sockControl) < 0 ||
!sockControl ||
kernel_connect(sockControl, sinControlAddr, sizeof (sinControlAddr)) < 0)
{
printk(KERN_ERR "banjosock_init: problem creating / binding CONTROL socket\n");
return -1;
}
// align the tx buffer in memory
sockTxBuf = &sockBuf[0] + (PKTALIGN - 1);
sockTxBuf -= (u32)sockTxBuf % PKTALIGN;
return 0;
}
void banjosock_cleanup(void)
{
if (sockData)
sock_release(sockData);
if (sockControl)
sock_release(sockControl);
}
static int banjosock_sendmesg(u32 type, u32 size, u32 param, u32 reserved)
{
// append a header and send it to the server
struct Header* h = (struct Header*)&sockTxBuf;
h->type = htonl(type);
h->size = htonl(size);
h->parameter = htonl(param);
h->reserved = htonl(reserved);
return _sendto(sockData, (void*)sockTxBuf, size + sizeof (struct Header),
(struct sockaddr_in*)&sinDataAddr);
}
static int banjosock_sendwindow(u32 window)
{
// send the next window request to the server via the control port
u32* l = (u32*)&sockTxBuf;
*l = htonl(window);
return _sendto(sockData, (void*)sockTxBuf, sizeof (u32),
(struct sockaddr_in*)&sinControlAddr);
}
int banjosock_handledata(void)
{
int ret = 0;
u32 recv, total;
char hdrbuf[sizeof (struct Header)];
struct Header* h = (struct Header*)&hdrbuf;
// get the header coming down the line
ret = _recv(sockData, hdrbuf, sizeof (struct Header), 0);
if (ret < 0)
{
printk(KERN_ERR "banjosock_handledata: failed to receive data from socket (%d)\n", ret);
return -1;
}
// convert to host
h->type = htonl(h->type);
h->size = htonl(h->size);
h->parameter = htonl(h->parameter);
h->reserved = htonl(h->reserved);
switch (h->type)
{
case ACK:
break;
case NAK:
break;
case EOT:
break;
case VIDEO_FRAME:
// get the data still remaining in queue
recv = 0;
total = h->size;
while (recv < total)
{
ret = _recv(sockData, (void*)(banjo_device->dma.buf + recv), total - recv, 0);
recv += ret;
// request more data at window intervals
if (recv < total && (recv % WINDOWSIZE) == 0)
{
ret = banjosock_sendwindow(WINDOWSIZE);
if (ret < 0)
{
printk(KERN_ERR "banjosock_handledata: failed to send window msg (%d)\n", ret);
return -1;
}
}
}
break;
}
return ret;
}
int banjosock_decueFeature(void)
{
int ret;
// de-cue the current feature
ret = banjosock_sendmesg(DECUE_FEATURE, 0, 0, 0);
if (ret < 0)
{
printk(KERN_ERR "banjosock_decueFeature: failed to send de-cue msg (%d)\n", ret);
return -1;
}
return banjosock_handledata();
}
int banjosock_cueFeature(const char* feature)
{
int ret;
// assemble the tx packet
char* pkt = (char*)sockTxBuf;
pkt += sizeof (struct Header);
strcpy(pkt, feature);
// cue the requested feature
ret = banjosock_sendmesg(CUE_FEATURE, strlen(feature), 0, 0);
if (ret < 0)
{
printk(KERN_ERR "banjosock_cueFeature: failed to send cue feature msg (%d)\n", ret);
return -1;
}
return banjosock_handledata();
}
int banjosock_requestFrame(int frame)
{
int ret;
// cue the requested feature
ret = banjosock_sendmesg(VIDEO_FRAME_REQUEST, 0, frame, WINDOWSIZE);
if (ret < 0)
{
printk(KERN_ERR "banjosock_requestFrame: failed to send request frame msg (%d)\n", ret);
return -1;
}
return banjosock_handledata();
}
int banjo_dmastatus_proc(char* buf, char** start, off_t offset, int count, int* eof, void* data)
{
int len = 0;
len += sprintf(buf + len, "\nBanjo Decoder - DMA");
len += sprintf(buf + len, "\n\tDCRN_DMASR\t: %08X", mfdcr(DMA2P40_SR));
len += sprintf(buf + len, "\n\trequests\t: %d", banjo_device->frames_request);
len += sprintf(buf + len, "\n\tframes sent\t: %d", banjo_device->frames_sent);
len += sprintf(buf + len, "\n\tnot ready\t: %d", banjo_device->frames_not_ready);
len += sprintf(buf + len, "\n\tdma error\t: %d", banjo_device->frames_dma_error);
len += sprintf(buf + len, "\n\n");
*eof = 1;
return len;
}
struct file_operations banjo_fops =
{
.owner = THIS_MODULE,
.llseek = 0,
.read = 0,
.write = 0,
.ioctl = banjo_ioctl,
.open = banjo_open,
.release = banjo_release,
};
static void banjo_setup_cdev(struct banjo_dev* dev, int index)
{
int devno = MKDEV(banjo_major, index);
cdev_init(&dev->cdev, &banjo_fops);
dev->cdev.owner = THIS_MODULE;
dev->cdev.ops = &banjo_fops;
cdev_add(&dev->cdev, devno, 1);
}
static void __init dma_init(void)
{
// setup the channel 0 control register
mtdcr(DMA2P40_CR0, DMA_CONFIG0);
// remap DMA buffer
banjo_device->dma.buf = ioremap(DMABUFFERBASE, DMABUFFERSIZE);
banjo_device->dma.flags = 0;
enable_per_ready(0);
}
static void __init init_interrupts(void)
{
// map interrupt handler for DMA status
request_irq(DMA_STATUS_IRQ, dma_status_int, SA_INTERRUPT,
DRIVER_NAME, dma_status_int);
// map interrupt handler for frame ready interrupt IRQ7
request_irq(FRAME_READY_IRQ, frame_req_int, SA_INTERRUPT,
DRIVER_NAME, frame_req_int);
}
static int __init banjo_init(void)
{
int result;
dev_t dev = MKDEV(banjo_major, 0);
printk(KERN_INFO "USL, Inc. Image Decoder driver v" DRIVER_VERSION "\n");
/*
* Register your major, and accept a dynamic number.
*/
if (banjo_major)
result = register_chrdev_region(dev, 0, DRIVER_NAME);
else
{
result = alloc_chrdev_region(&dev, 0, 0, DRIVER_NAME);
banjo_major = MAJOR(dev);
}
if (result < 0)
return result;
// remap the FPGA registers
banjo_regmap = ioremap(BANJO_DECODER_BASE, BANJO_REGISTERMAP_SIZE);
// remap GPIO1 port address
gpio1_or = ioremap(GPIO1_OR, sizeof (long));
// allocate all device structures
banjo_device = kmalloc(sizeof (struct banjo_dev), GFP_KERNEL);
memset(banjo_device, 0, sizeof (struct banjo_dev));
// register character devices with the kernel
banjo_setup_cdev(banjo_device, 0);
// create /proc fs entries
create_proc_read_entry("banjodma", 0, NULL, banjo_dmastatus_proc, NULL);
// initialize DMA
dma_init();
// initialize interrupts
init_interrupts();
return 0;
}
static void __exit banjo_exit(void)
{
free_irq(FRAME_READY_IRQ, NULL);
free_irq(DMA_STATUS_IRQ, NULL);
banjosock_cleanup();
cdev_del(&banjo_device->cdev);
kfree(banjo_device);
remove_proc_entry("banjodma", NULL);
iounmap(gpio1_or);
iounmap(banjo_regmap);
iounmap(banjo_device->dma.buf);
unregister_chrdev_region(MKDEV(banjo_major, 0), 1);
}
module_init(banjo_init);
module_exit(banjo_exit);
^ permalink raw reply
* Re: Continued serial headaches
From: Scott Wood @ 2007-10-30 18:02 UTC (permalink / raw)
To: Alan Bennett; +Cc: linuxppc-dev
In-Reply-To: <bfa0697f0710301042j5d899790k753050f22079f3d6@mail.gmail.com>
Alan Bennett wrote:
> Am I missing something in the PRAM areas?
> SMC1 (ttyCPM0...)
> e0008000 : 00c000e0 30300020 00000000 eefe3e7a
> e0008010 : 00c07331 11b6b05f 30440000 07f4d082
> e0008020 : 00e00003 746562ec d98ceffd 0dec67e3
> e0008030 : df7b2db5 5f0bf2dc 00205ce8 00010000
> e0008040 : 00000000 0000fc9d 00000000 d08a0000
> e0008050 : 80008000 80008000 80008000 80008000
> SCC1
> e0008000 : 00c000e0 30300020 00000000 eefe3e7a
> e0008010 : 00c07331 11b6b05f 30440000 07f4d082
> e0008020 : 00e00003 746562ec d98ceffd 0dec67e3
> e0008030 : df7b2db5 5f0bf2dc 00205ce8 00010000
> e0008040 : 00000000 0000fc9d 00000000 d08a0000
> e0008050 : 80008000 80008000 80008000 80008000
I'm fairly sure you don't want SMC1 and SCC1 to have the same PRAM areas...
Assuming that was just a typo, I don't know what could be wrong. You'll
just have to debug it. :-)
-Scott
^ permalink raw reply
* [PATCH v2] using mii-bitbang on different processor ports
From: Sergej Stepanov @ 2007-10-30 18:10 UTC (permalink / raw)
To: linuxppc-dev, netdev, jgarzik
The patch makes possible to have mdio and mdc pins on different physical ports
also for CONFIG_PPC_CPM_NEW_BINDING.
To setup it in the device tree:
reg = <10d40 14 10d60 14>; // mdc: 0x10d40, mdio: 0x10d60
or
reg = <10d40 14>; // mdc and mdio have the same offset 10d40
The approach was taken from older version.
Signed-off-by: Sergej Stepanov <Sergej.Stepanov@ids.de>
--
diff --git a/drivers/net/fs_enet/mii-bitbang.c b/drivers/net/fs_enet/mii-bitbang.c
index b8e4a73..eea5feb 100644
--- a/drivers/net/fs_enet/mii-bitbang.c
+++ b/drivers/net/fs_enet/mii-bitbang.c
@@ -29,12 +29,16 @@
#include "fs_enet.h"
-struct bb_info {
- struct mdiobb_ctrl ctrl;
+struct bb_port {
__be32 __iomem *dir;
__be32 __iomem *dat;
- u32 mdio_msk;
- u32 mdc_msk;
+ u32 msk;
+};
+
+struct bb_info {
+ struct mdiobb_ctrl ctrl;
+ struct bb_port mdc;
+ struct bb_port mdio;
};
/* FIXME: If any other users of GPIO crop up, then these will have to
@@ -62,18 +66,18 @@ static inline void mdio_dir(struct mdiobb_ctrl *ctrl, int dir)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (dir)
- bb_set(bitbang->dir, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dir, bitbang->mdio.msk);
else
- bb_clr(bitbang->dir, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dir, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dir);
+ in_be32(bitbang->mdio.dir);
}
static inline int mdio_read(struct mdiobb_ctrl *ctrl)
{
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
- return bb_read(bitbang->dat, bitbang->mdio_msk);
+ return bb_read(bitbang->mdio.dat, bitbang->mdio.msk);
}
static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
@@ -81,12 +85,12 @@ static inline void mdio(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdio_msk);
+ bb_set(bitbang->mdio.dat, bitbang->mdio.msk);
else
- bb_clr(bitbang->dat, bitbang->mdio_msk);
+ bb_clr(bitbang->mdio.dat, bitbang->mdio.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdio.dat);
}
static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
@@ -94,12 +98,12 @@ static inline void mdc(struct mdiobb_ctrl *ctrl, int what)
struct bb_info *bitbang = container_of(ctrl, struct bb_info, ctrl);
if (what)
- bb_set(bitbang->dat, bitbang->mdc_msk);
+ bb_set(bitbang->mdc.dat, bitbang->mdc.msk);
else
- bb_clr(bitbang->dat, bitbang->mdc_msk);
+ bb_clr(bitbang->mdc.dat, bitbang->mdc.msk);
/* Read back to flush the write. */
- in_be32(bitbang->dat);
+ in_be32(bitbang->mdc.dat);
}
static struct mdiobb_ops bb_ops = {
@@ -114,23 +118,23 @@ static struct mdiobb_ops bb_ops = {
static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
struct device_node *np)
{
- struct resource res;
+ struct resource res[2];
const u32 *data;
int mdio_pin, mdc_pin, len;
struct bb_info *bitbang = bus->priv;
- int ret = of_address_to_resource(np, 0, &res);
+ int ret = of_address_to_resource(np, 0, &res[0]);
if (ret)
return ret;
- if (res.end - res.start < 13)
+ if (res[0].end - res[0].start < 13)
return -ENODEV;
/* This should really encode the pin number as well, but all
* we get is an int, and the odds of multiple bitbang mdio buses
* is low enough that it's not worth going too crazy.
*/
- bus->id = res.start;
+ bus->id = res[0].start;
data = of_get_property(np, "fsl,mdio-pin", &len);
if (!data || len != 4)
@@ -142,15 +146,32 @@ static int __devinit fs_mii_bitbang_init(struct mii_bus *bus,
return -ENODEV;
mdc_pin = *data;
- bitbang->dir = ioremap(res.start, res.end - res.start + 1);
- if (!bitbang->dir)
+ bitbang->mdc.dir = ioremap(res[0].start, res[0].end - res[0].start + 1);
+ if (!bitbang->mdc.dir)
return -ENOMEM;
- bitbang->dat = bitbang->dir + 4;
- bitbang->mdio_msk = 1 << (31 - mdio_pin);
- bitbang->mdc_msk = 1 << (31 - mdc_pin);
+ bitbang->mdc.dat = bitbang->mdc.dir + 4;
+ if( !of_address_to_resource(np, 1, &res[1])) {
+ if (res[1].end - res[1].start < 13)
+ goto bad_resource;
+ bitbang->mdio.dir = ioremap(res[1].start, res[1].end - res[1].start + 1);
+ if (!bitbang->mdio.dir)
+ goto unmap_and_exit;
+ bitbang->mdio.dat = bitbang->mdio.dir + 4;
+ } else {
+ bitbang->mdio.dir = bitbang->mdc.dir;
+ bitbang->mdio.dat = bitbang->mdc.dat;
+ }
+ bitbang->mdio.msk = 1 << (31 - mdio_pin);
+ bitbang->mdc.msk = 1 << (31 - mdc_pin);
return 0;
+bad_resource:
+ iounmap(bitbang->mdc.dir);
+ return -ENODEV;
+unmap_and_exit:
+ iounmap(bitbang->mdc.dir);
+ return -ENOMEM;
}
static void __devinit add_phy(struct mii_bus *bus, struct device_node *np)
@@ -220,7 +241,9 @@ out_free_irqs:
dev_set_drvdata(&ofdev->dev, NULL);
kfree(new_bus->irq);
out_unmap_regs:
- iounmap(bitbang->dir);
+ if (bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
out_free_bus:
kfree(new_bus);
out_free_priv:
@@ -238,7 +261,9 @@ static int fs_enet_mdio_remove(struct of_device *ofdev)
free_mdio_bitbang(bus);
dev_set_drvdata(&ofdev->dev, NULL);
kfree(bus->irq);
- iounmap(bitbang->dir);
+ if ( bitbang->mdio.dir != bitbang->mdc.dir)
+ iounmap(bitbang->mdio.dir);
+ iounmap(bitbang->mdc.dir);
kfree(bitbang);
kfree(bus);
^ permalink raw reply related
* [RFC] hotplug memory remove - walk_memory_resource for ppc64
From: Badari Pulavarty @ 2007-10-30 19:19 UTC (permalink / raw)
To: Paul Mackerras, KAMEZAWA Hiroyuki; +Cc: linuxppc-dev, anton, linux-mm
In-Reply-To: <18178.52359.953289.638736@cargo.ozlabs.ibm.com>
Hi KAME,
As I mentioned while ago, ppc64 does not export information about
"system RAM" in /proc/iomem. Looking at the code and usage
scenerios I am not sure what its really serving. Could you
explain what its purpose & how the range can be invalid ?
At least on ppc64, all the memory ranges we get passed comes from
/sysfs memblock information and they are guaranteed to match
device-tree entries. On ppc64, each 16MB chunk has a /sysfs entry
and it will be part of the /proc/device-tree entry. Since we do
"online" or "offline" to /sysfs entries to add/remove pages -
these ranges are guaranteed to be valid.
Since this check is redundant for ppc64, I propose following patch.
Is this acceptable ? If some one really really wants, I can code
up this to walk lmb or /proc/device-tree and verify the range &
adjust the entries for overlap (I don't see how that can happen).
Paul & Kame, please comment.
Thanks,
Badari
---
arch/powerpc/Kconfig | 3 +++
arch/powerpc/mm/mem.c | 13 +++++++++++++
kernel/resource.c | 2 +-
3 files changed, 17 insertions(+), 1 deletion(-)
Index: linux-2.6.24-rc1/arch/powerpc/mm/mem.c
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/mm/mem.c 2007-10-30 07:39:16.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/mm/mem.c 2007-10-30 10:05:09.000000000 -0800
@@ -129,6 +129,19 @@ int __devinit arch_add_memory(int nid, u
return __add_pages(zone, start_pfn, nr_pages);
}
+/*
+ * I don't think we really need to do anything here to validate the memory
+ * range or walk the memory resource in lmb or device-tree. Only way we get
+ * the memory range here is through /sysfs in 16MB chunks and we are guaranteed
+ * to have a corresponding device-tree entry.
+ */
+int
+walk_memory_resource(unsigned long start_pfn, unsigned long nr_pages, void *arg,
+ int (*func)(unsigned long, unsigned long, void *))
+{
+ return (*func)(start_pfn, nr_pages, arg);
+}
+
#endif /* CONFIG_MEMORY_HOTPLUG */
#ifdef CONFIG_MEMORY_HOTREMOVE
Index: linux-2.6.24-rc1/kernel/resource.c
===================================================================
--- linux-2.6.24-rc1.orig/kernel/resource.c 2007-10-23 20:50:57.000000000 -0700
+++ linux-2.6.24-rc1/kernel/resource.c 2007-10-30 08:58:41.000000000 -0800
@@ -228,7 +228,7 @@ int release_resource(struct resource *ol
EXPORT_SYMBOL(release_resource);
-#ifdef CONFIG_MEMORY_HOTPLUG
+#if defined(CONFIG_MEMORY_HOTPLUG) && !defined(CONFIG_ARCH_HAS_WALK_MEMORY)
/*
* Finds the lowest memory reosurce exists within [res->start.res->end)
* the caller must specify res->start, res->end, res->flags.
Index: linux-2.6.24-rc1/arch/powerpc/Kconfig
===================================================================
--- linux-2.6.24-rc1.orig/arch/powerpc/Kconfig 2007-10-30 07:39:17.000000000 -0800
+++ linux-2.6.24-rc1/arch/powerpc/Kconfig 2007-10-30 08:54:57.000000000 -0800
@@ -234,6 +234,9 @@ config HOTPLUG_CPU
config ARCH_ENABLE_MEMORY_HOTPLUG
def_bool y
+config ARCH_HAS_WALK_MEMORY
+ def_bool y
+
config ARCH_ENABLE_MEMORY_HOTREMOVE
def_bool y
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Josh Boyer @ 2007-10-30 18:17 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
On Tue, 30 Oct 2007 19:45:11 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> The following patches add PowerPC 440GRx Rainier board support.
> The board is almost identical to Sequoia, but doesn't have USB
> and FPU is not supported.
General FYI, I'm probably going to queue these up for .25. We should
be in bug-fix mode for .24.
josh
^ permalink raw reply
* Re: [PATCH v2] using mii-bitbang on different processor ports
From: Scott Wood @ 2007-10-30 18:23 UTC (permalink / raw)
To: Sergej Stepanov; +Cc: linuxppc-dev, jgarzik, netdev
In-Reply-To: <1193767812.6244.46.camel@p60635-ste.ids.de>
Sergej Stepanov wrote:
> + if( !of_address_to_resource(np, 1, &res[1])) {
The spacing is still wrong.
> - iounmap(bitbang->dir);
> + if ( bitbang->mdio.dir != bitbang->mdc.dir)
> + iounmap(bitbang->mdio.dir);
> + iounmap(bitbang->mdc.dir);
And here.
-Scott
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Valentine Barshak @ 2007-10-30 18:31 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071030131703.3b4b4056@weaponx.rchland.ibm.com>
Josh Boyer wrote:
> On Tue, 30 Oct 2007 19:45:11 +0300
> Valentine Barshak <vbarshak@ru.mvista.com> wrote:
>
>> The following patches add PowerPC 440GRx Rainier board support.
>> The board is almost identical to Sequoia, but doesn't have USB
>> and FPU is not supported.
>
> General FYI, I'm probably going to queue these up for .25. We should
> be in bug-fix mode for .24.
OK, thanks,
Valentine.
>
> josh
^ permalink raw reply
* Re: [PATCH] pegasos_eth.c: Fix compile error over MV643XX_ defines
From: Jeff Garzik @ 2007-10-30 18:32 UTC (permalink / raw)
To: Dale Farnsworth
Cc: Tzachi Perelstein, netdev, Luis R. Rodriguez, Lennert Buytenhek,
linuxppc-dev
In-Reply-To: <20071029223900.GA7097@xyzzy.farnsworth.org>
Dale Farnsworth wrote:
> On Mon, Oct 29, 2007 at 05:27:29PM -0400, Luis R. Rodriguez wrote:
>> This commit made an incorrect assumption:
>> --
>> Author: Lennert Buytenhek <buytenh@wantstofly.org>
>> Date: Fri Oct 19 04:10:10 2007 +0200
>>
>> mv643xx_eth: Move ethernet register definitions into private header
>>
>> Move the mv643xx's ethernet-related register definitions from
>> include/linux/mv643xx.h into drivers/net/mv643xx_eth.h, since
>> they aren't of any use outside the ethernet driver.
>>
>> Signed-off-by: Lennert Buytenhek <buytenh@marvell.com>
>> Acked-by: Tzachi Perelstein <tzachi@marvell.com>
>> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
>> --
>>
>> arch/powerpc/platforms/chrp/pegasos_eth.c made use of a 3 defines there.
>>
>> mcgrof@pogo:~/devel/wireless-2.6$ git-describe
>>
>> v2.6.24-rc1-138-g0119130
>>
>> This patch fixes this by internalizing 3 defines onto pegasos which are
>> simply no longer available elsewhere. Without this your compile will fail
>
> That compile failure was fixed in commit
> 30e69bf4cce16d4c2dcfd629a60fcd8e1aba9fee by Al Viro.
>
> However, as I examine that commit, I see that it defines offsets from
> the eth block in the chip, rather than the full chip registeri block
> as the Pegasos 2 code expects. So, I think it fixes the compile
> failure, but leaves the Pegasos 2 broken.
>
> Luis, do you have Pegasos 2 hardware? Can you (or anyone) verify that
> the following patch is needed for the Pegasos 2?
>
> Thanks,
> -Dale
>
> ---------------------------------
>
> mv643xx_eth: Fix MV643XX_ETH offsets used by Pegasos 2
>
> In the mv643xx_eth driver, we now use offsets from the ethernet
> register block within the chip, but the pegasos 2 platform still
> needs offsets from the full chip's register base address.
>
> Signed-off-by: Dale Farnsworth <dale@farnsworth.org>
> ---
> include/linux/mv643xx_eth.h | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/include/linux/mv643xx_eth.h b/include/linux/mv643xx_eth.h
> index 8df230a..30e11aa 100644
> --- a/include/linux/mv643xx_eth.h
> +++ b/include/linux/mv643xx_eth.h
> @@ -8,9 +8,9 @@
> #define MV643XX_ETH_NAME "mv643xx_eth"
> #define MV643XX_ETH_SHARED_REGS 0x2000
> #define MV643XX_ETH_SHARED_REGS_SIZE 0x2000
> -#define MV643XX_ETH_BAR_4 0x220
> -#define MV643XX_ETH_SIZE_REG_4 0x224
> -#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x0290
> +#define MV643XX_ETH_BAR_4 0x2220
> +#define MV643XX_ETH_SIZE_REG_4 0x2224
> +#define MV643XX_ETH_BASE_ADDR_ENABLE_REG 0x2290
applied
^ permalink raw reply
* [PATCH] [Powerpc V2.1] fix switch_slb handling of 1T ESID values
From: Will Schmidt @ 2007-10-30 18:59 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[Powerpc] fix switch_slb handling of 1T ESID values
Now that we have 1TB segment size support, we need to be using the
GET_ESID_1T macro when comparing ESID values for pc,stack, and
unmapped_base within switch_slb(). A new helper function called
esids_match() contains the logic for deciding when to call GET_ESID
and GET_ESID_1T.
This also happens to fix a duplicate-slb-entry inspired machine-check
exception I was seeing when trying to run java on a power6 partition.
Tested on power6 and power5.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
Just a bit of whitespace cosmetic touchup in this version, as suggested
by Stephen Rothwell.
---
arch/powerpc/mm/slb.c | 34 +++++++++++++++++++++++++++++++---
1 files changed, 31 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/mm/slb.c b/arch/powerpc/mm/slb.c
index bbd2c51..8cbbfab 100644
--- a/arch/powerpc/mm/slb.c
+++ b/arch/powerpc/mm/slb.c
@@ -148,6 +148,35 @@ void slb_vmalloc_update(void)
slb_flush_and_rebolt();
}
+/* Helper function to compare esids. There are four cases to handle.
+ * 1. The system is not 1T segment size capable. Use the GET_ESID compare.
+ * 2. The system is 1T capable, both addresses are < 1T, use the GET_ESID compare.
+ * 3. The system is 1T capable, only one of the two addresses is > 1T. This is not a match.
+ * 4. The system is 1T capable, both addresses are > 1T, use the GET_ESID_1T macro to compare.
+ */
+static inline int esids_match(unsigned long addr1, unsigned long addr2)
+{
+ int esid_1t_count;
+
+ /* System is not 1T segment size capable. */
+ if (!cpu_has_feature(CPU_FTR_1T_SEGMENT))
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ esid_1t_count = (((addr1 >> SID_SHIFT_1T) != 0) +
+ ((addr2 >> SID_SHIFT_1T) != 0));
+
+ /* both addresses are < 1T */
+ if (esid_1t_count == 0)
+ return (GET_ESID(addr1) == GET_ESID(addr2));
+
+ /* One address < 1T, the other > 1T. Not a match */
+ if (esid_1t_count == 1)
+ return 0;
+
+ /* Both addresses are > 1T. */
+ return (GET_ESID_1T(addr1) == GET_ESID_1T(addr2));
+}
+
/* Flush all user entries from the segment table of the current processor. */
void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
{
@@ -193,15 +222,14 @@ void switch_slb(struct task_struct *tsk, struct mm_struct *mm)
return;
slb_allocate(pc);
- if (GET_ESID(pc) == GET_ESID(stack))
+ if (esids_match(pc,stack))
return;
if (is_kernel_addr(stack))
return;
slb_allocate(stack);
- if ((GET_ESID(pc) == GET_ESID(unmapped_base))
- || (GET_ESID(stack) == GET_ESID(unmapped_base)))
+ if (esids_match(pc,unmapped_base) || esids_match(stack,unmapped_base))
return;
if (is_kernel_addr(unmapped_base))
^ permalink raw reply related
* RE: RFC: replace device_type with new "class" property?
From: Yoder Stuart-B08248 @ 2007-10-30 19:06 UTC (permalink / raw)
To: Wood Scott-B07421; +Cc: Olof Johansson, linuxppc-dev, David Gibson
In-Reply-To: <20071030163343.GA4517@loki.buserror.net>
=20
> -----Original Message-----
> From: Wood Scott-B07421=20
> Sent: Tuesday, October 30, 2007 11:34 AM
> To: Yoder Stuart-B08248
> Cc: David Gibson; Olof Johansson; linuxppc-dev@ozlabs.org
> Subject: Re: RFC: replace device_type with new "class" property?
>=20
> On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
> > mpic: pic@40000 {
> > clock-frequency =3D <0>;
> > interrupt-controller;
> > #address-cells =3D <0>;
> > #interrupt-cells =3D <2>;
> > reg =3D <40000 40000>;
> > compatible =3D "fsl,xyz";
> > big-endian;
> > }
> >=20
> > Note-- I removed the device_type property and changed
> > compatible somewhat. How are you going to find where
> > the meaning interrupt controller's interrupt cells are
> > defined? What spec will you look at?
>=20
> The binding for fsl,xyz.
Not every string listed in compatible has a spec=20
backing it (or should be required to). You would
have to go look at the source code and cross your
fingers that the comments were sufficient.
Another good reason for device_type-- it helps=20
distinguish between two similar classes of devices.
Both "open-pic" and "isa-pic" look very similar but
have different encodings of their interrupt cells.
Without a device_type it may be difficult or impossible
to distinguish them unless the "name" and
"compatible" are luckily clear enough.
Stuart
^ permalink raw reply
* Re: Gianfar skb panic when bonding a VLAN interface
From: Jay Vosburgh @ 2007-10-30 19:07 UTC (permalink / raw)
To: Demke Torsten-atd012; +Cc: linuxppc-dev
In-Reply-To: <67194FEE6056B947B4EF756C9E497A2E01DB237A@zuk35exm60.ds.mot.com>
Demke Torsten-atd012 <torsten.demke@motorola.com> wrote:
>I tried to ping over a bonded VLAN tagged interface.
>(e.g -> ifenslave bond0 eth3.24)
[...]
>It seems that the skb headroom is to small. How can I solve this?
>I could insert skb_realloc_headroom() call, but where it's the best
>place then?
>What about alignement?
What kernel are you using? There was a fix applied to the
bonding driver about a year ago to resolve this problem with gianfar:
commit 54ef313714070b397d3857289f0fd099b7643631
Author: Jay Vosburgh <fubar@us.ibm.com>
Date: Fri Sep 22 21:53:39 2006 -0700
[PATCH] bonding: Handle large hard_header_len
The bonding driver fails to adjust its hard_header_len when enslaving
interfaces. Whenever an interface with a hard_header_len greater than the
ETH_HLEN default is enslaved, the potential for an oops exists, and if the
oops happens while responding to an arp request, for example, the system
panics. GIANFAR devices may use an extended hard_header for VLAN or
hardware checksumming. Enslaving such a device and then transmitting over
it causes a kernel panic.
Patch modified from submitter's original, but submitter agreed with this
patch in private email.
Signed-off-by: Mark Huth <mhuth@mvista.com>
Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
-J
---
-Jay Vosburgh, IBM Linux Technology Center, fubar@us.ibm.com
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: Grant Likely @ 2007-10-30 19:38 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, David Gibson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F2872@az33exm25.fsl.freescale.net>
On 10/30/07, Yoder Stuart-B08248 <stuart.yoder@freescale.com> wrote:
> Another good reason for device_type-- it helps
> distinguish between two similar classes of devices.
> Both "open-pic" and "isa-pic" look very similar but
> have different encodings of their interrupt cells.
> Without a device_type it may be difficult or impossible
> to distinguish them unless the "name" and
> "compatible" are luckily clear enough.
I don't think you want to go down that path. If your compatible list
does not uniquely describe what the device is (followed by a list of
devices it is compatible with); then it is not specific enough. It's
fine for a device driver to go looking at other properties to get more
details; but drivers should primarily bind on the compatible list.
In other words; device_type and/or class are a coarser grained
description of the device than the compatible list. If you match on
compatible; why would there be any need at all to look at 'name',
'device_type' or the proposed 'class' properties?
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* [patch 05/28] Add cmpxchg64 and cmpxchg64_local to powerpc
From: Mathieu Desnoyers @ 2007-10-30 19:16 UTC (permalink / raw)
To: akpm, linux-kernel, matthew, linux-arch, penberg, linux-mm,
Christoph Lameter
Cc: Paul Mackerras, Mathieu Desnoyers, linuxppc-dev
In-Reply-To: <20071030191557.947156623@polymtl.ca>
Make sure that at least cmpxchg64_local is available on all architectures to use
for unsigned long long values.
Signed-off-by: Mathieu Desnoyers <mathieu.desnoyers@polymtl.ca>
Acked-by: Paul Mackerras <paulus@samba.org>
CC: linuxppc-dev@ozlabs.org
---
include/asm-powerpc/system.h | 6 ++++++
1 file changed, 6 insertions(+)
Index: linux-2.6-lttng/include/asm-powerpc/system.h
===================================================================
--- linux-2.6-lttng.orig/include/asm-powerpc/system.h 2007-09-24 10:50:11.000000000 -0400
+++ linux-2.6-lttng/include/asm-powerpc/system.h 2007-09-24 11:01:04.000000000 -0400
@@ -488,6 +488,12 @@ __cmpxchg_local(volatile void *ptr, unsi
*/
#define NET_IP_ALIGN 0
#define NET_SKB_PAD L1_CACHE_BYTES
+
+#define cmpxchg64 cmpxchg
+#define cmpxchg64_local cmpxchg_local
+#else
+#include <asm-generic/cmpxchg-local.h>
+#define cmpxchg64_local(ptr,o,n) __cmpxchg64_local_generic((ptr), (o), (n))
#endif
#define arch_align_stack(x) (x)
--
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68
^ permalink raw reply
* Re: [PATCH 3/4] PowerPC: 440GRx Rainier board support.
From: Arnd Bergmann @ 2007-10-30 19:59 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20071030165739.GA22126@ru.mvista.com>
T24gVHVlc2RheSAzMCBPY3RvYmVyIDIwMDcsIFZhbGVudGluZSBCYXJzaGFrIHdyb3RlOgo+ICtz
dGF0aWMgc3RydWN0IG9mX2RldmljZV9pZCByYWluaWVyX29mX2J1c1tdID0gewo+ICugoKCgoKCg
eyAuY29tcGF0aWJsZSA9ICJpYm0scGxiNCIsIH0sCj4gK6CgoKCgoKB7IC5jb21wYXRpYmxlID0g
ImlibSxvcGIiLCB9LAo+ICugoKCgoKCgeyAuY29tcGF0aWJsZSA9ICJpYm0sZWJjIiwgfSwKPiAr
oKCgoKCgoHt9LAo+ICt9Owo+ICsKPiArc3RhdGljIGludCBfX2luaXQgcmFpbmllcl9kZXZpY2Vf
cHJvYmUodm9pZCkKPiArewo+ICugoKCgoKCgaWYgKCFtYWNoaW5lX2lzKHJhaW5pZXIpKQo+ICug
oKCgoKCgoKCgoKCgoKByZXR1cm4gMDsKPiArCj4gK6CgoKCgoKBvZl9wbGF0Zm9ybV9idXNfcHJv
YmUoTlVMTCwgcmFpbmllcl9vZl9idXMsIE5VTEwpOwo+ICsKPiAroKCgoKCgoHJldHVybiAwOwo+
ICt9Cj4gK2RldmljZV9pbml0Y2FsbChyYWluaWVyX2RldmljZV9wcm9iZSk7Cj4gKwo+ICtzdGF0
aWMgaW50IF9faW5pdCByYWluaWVyX3Byb2JlKHZvaWQpCj4gK3sKPiAroKCgoKCgoHVuc2lnbmVk
IGxvbmcgcm9vdCA9IG9mX2dldF9mbGF0X2R0X3Jvb3QoKTsKPiArCj4gK6CgoKCgoKBpZiAoIW9m
X2ZsYXRfZHRfaXNfY29tcGF0aWJsZShyb290LCAiYW1jYyxyYWluaWVyIikpCj4gK6CgoKCgoKCg
oKCgoKCgoHJldHVybiAwOwo+ICsKPiAroKCgoKCgoHJldHVybiAxOwo+ICt9Cj4gKwo+ICtkZWZp
bmVfbWFjaGluZShyYWluaWVyKSB7Cj4gK6CgoKCgoKAubmFtZSCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoD0gIlJhaW5pZXIiLAo+ICugoKCgoKCgLnByb2JlIKCgoKCgoKCgoKCgoKCgoKCgoKCg
oKCgoKA9IHJhaW5pZXJfcHJvYmUsCj4gK6CgoKCgoKAucHJvZ3Jlc3MgoKCgoKCgoKCgoKCgoKCg
oKCgoKCgoD0gdWRiZ19wcm9ncmVzcywKPiAroKCgoKCgoC5pbml0X0lSUSCgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgPSB1aWNfaW5pdF90cmVlLAo+ICugoKCgoKCgLmdldF9pcnEgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKA9IHVpY19nZXRfaXJxLAo+ICugoKCgoKCgLnJlc3RhcnSgoKCgoKCgoKCgoKCg
oKCgoKCgoKCgoKA9IHBwYzQ0eF9yZXNldF9zeXN0ZW0sCj4gK6CgoKCgoKAuY2FsaWJyYXRlX2Rl
Y3KgoKCgoKCgoKCgoKCgoKCgoD0gZ2VuZXJpY19jYWxpYnJhdGVfZGVjciwKPiArfTsKCldvdywg
dGhpcyBpcyBnZXR0aW5nIHJlYWxseSBzbWFsbCB0aGVzZSBkYXlzLiBJIHdvbmRlciBpZiB3ZSBz
aG91bGQgYWRkIHR3bwptb3JlIGdlbmVyaWMgaGVscGVycyB0byB0dXJuIHRoaXMgaW50byBqdXN0
CgpkZWZpbmVfbWFjaGluZShyYWluaWVyKSB7CiAgICAgICAubmFtZSAgICAgICAgICAgICAgICAg
ICAgICAgICAgID0gIlJhaW5pZXIiLAogICAgICAgLmNvbXBhdGlibGUgICAgICAgICAgICAgICAg
ICAgICA9ICJhbWNjLHJhaW5pZXIiLCAgICAgICAgIC8qIG5ldyAqLwogICAgICAgLnByb2JlX2J1
c2VzCQkgICAgICAgPSAmNHh4X2dlbmVyaWNfYnVzX3Byb2JlLCAvKiBuZXcgKi8KICAgICAgIC5w
cm9ncmVzcyAgICAgICAgICAgICAgICAgICAgICAgPSB1ZGJnX3Byb2dyZXNzLAogICAgICAgLmlu
aXRfSVJRICAgICAgICAgICAgICAgICAgICAgICA9IHVpY19pbml0X3RyZWUsCiAgICAgICAuZ2V0
X2lycSAgICAgICAgICAgICAgICAgICAgICAgID0gdWljX2dldF9pcnEsCiAgICAgICAucmVzdGFy
dCAgICAgICAgICAgICAgICAgICAgICAgID0gcHBjNDR4X3Jlc2V0X3N5c3RlbSwKICAgICAgIC5j
YWxpYnJhdGVfZGVjciAgICAgICAgICAgICAgICAgPSBnZW5lcmljX2NhbGlicmF0ZV9kZWNyLAp9
OwoKCUFybmQgPD48Cg==
^ permalink raw reply
* Re: [PATCH 0/4] PowerPC: 440GRx Rainier board support.
From: Josh Boyer @ 2007-10-30 20:16 UTC (permalink / raw)
To: Valentine Barshak; +Cc: linuxppc-dev
In-Reply-To: <20071030164511.GA21973@ru.mvista.com>
On Tue, 30 Oct 2007 19:45:11 +0300
Valentine Barshak <vbarshak@ru.mvista.com> wrote:
> The following patches add PowerPC 440GRx Rainier board support.
> The board is almost identical to Sequoia, but doesn't have USB
> and FPU is not supported.
So why do we need anything other than the DTS and the defconfig? I
would think the sequoia wrapper and platform files would suffice
completely for this.
josh
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
From: Benjamin Herrenschmidt @ 2007-10-30 20:16 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev
In-Reply-To: <20071030072310.51870c65@weaponx.rchland.ibm.com>
> > Fortunately, we don't support SMP on these or this solution wouldn't
> > work.
>
> We should mark 44x BROKEN on SMP in Kconfig.
Can we enable SMP on 44x at all currently ?
> No arch/ppc fix? I know we all want it to die as soon as possible, but
> still... :)
Yeah, I didn't do it yet, which is one reason this patch is marked
RFC :-)
> > /* interrupts are hard-disabled at this point */
> > restore:
> > +#ifdef CONFIG_44x
> > + lis r4,icache_44x_need_flush@ha
> > + lwz r5,icache_44x_need_flush@l(r4)
> > + cmplwi cr0,r5,0
> > + beq+ 1f
> > + iccci r0,r0
> > + li r6,0
> > + iccci r0,r0
> > + stw r6,icache_44x_need_flush@l(r4)
> > +1:
>
> Why two iccci's here?
No idea... thinko/typo.
Ben.
^ permalink raw reply
* Re: [RFC/PATCH] powerpc: Deal with 44x virtually tagged icache
From: Josh Boyer @ 2007-10-30 21:07 UTC (permalink / raw)
To: benh; +Cc: linuxppc-dev
In-Reply-To: <1193775391.9928.78.camel@pasglop>
On Wed, 31 Oct 2007 07:16:31 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
>
> > > Fortunately, we don't support SMP on these or this solution wouldn't
> > > work.
> >
> > We should mark 44x BROKEN on SMP in Kconfig.
>
> Can we enable SMP on 44x at all currently ?
Not without editing the Kconfig.cputypes file. I was thinking of being
a bit proactive so people didn't just add || 44x to it and think it
would work. But it's minor.
> > No arch/ppc fix? I know we all want it to die as soon as possible, but
> > still... :)
>
> Yeah, I didn't do it yet, which is one reason this patch is marked
> RFC :-)
Fair enough.
> > > /* interrupts are hard-disabled at this point */
> > > restore:
> > > +#ifdef CONFIG_44x
> > > + lis r4,icache_44x_need_flush@ha
> > > + lwz r5,icache_44x_need_flush@l(r4)
> > > + cmplwi cr0,r5,0
> > > + beq+ 1f
> > > + iccci r0,r0
> > > + li r6,0
> > > + iccci r0,r0
> > > + stw r6,icache_44x_need_flush@l(r4)
> > > +1:
> >
> > Why two iccci's here?
>
> No idea... thinko/typo.
And here I thought you were being extra careful ;)
josh
^ permalink raw reply
* Re: Bootup support for watchdog with short timeout (touch_nmi_watchdog()?)
From: Wolfgang Denk @ 2007-10-30 21:23 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev, linux-kernel, Lennart Sorensen
In-Reply-To: <200710301216.15033.stefan.roese@gmail.com>
Hello Stefan,
In message <200710301216.15033.stefan.roese@gmail.com> you wrote:
>
> I already have it running on my system using a quick hack (see patch below) in
> include/asm-ppc/nmi.h (yes, still arch/ppc for now :-( ). But for a clean
> implementation, that has chances for upstream merge (in arch/powerpc later),
> I would really like to hear if I should move on further this way.
>
> My impression is, that changing the name from touch_nmi_watchdog() to
> something like touch_watchdog(), and therefore touching lots of files, makes
> it more unlikely that this resulting patch will get accepted. But
> implementing this bootup watchdog support in asm-ppc(asm-powerpc)/nmi.h
> header seems also not totally correct, since it's not really an NMI in this
> case.
Indeed. Using the header file <asm/nmi.h> is seriously misleading for
the PowerPC version, as is the function name touch_nmi_watchdog() -
thius has nothing to do with NMIs on PowerPC, and most probably not on
any other non-x86 architecture as well.
To make this mechanism generally usable (which is a good idea IMO) the
names should be changed to get rid of the "nmi" reference.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd@denx.de
It may be that your whole purpose in life is simply to serve as a
warning to others.
^ permalink raw reply
* PPC405GP Walnut irq patch
From: Steven A. Falco @ 2007-10-30 21:06 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 439 bytes --]
Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
the ethernet interrupts in the walnut.dts file doesn't match the
documentation. I discovered this when porting the BSP to a custom board
- the ethernet would not work. The attached patch corrects that.
This is the first patch I am submitting, so please advise me if there is
anything I should do differently.
Signed-off-by: Steve Falco <sfalco at harris.com>
[-- Attachment #2: irq.patch --]
[-- Type: text/x-patch, Size: 578 bytes --]
--- walnut.dts.orig 2007-10-30 15:27:49.000000000 -0400
+++ walnut.dts 2007-10-30 15:29:40.000000000 -0400
@@ -67,7 +67,7 @@
num-tx-chans = <2>;
num-rx-chans = <1>;
interrupt-parent = <&UIC0>;
- interrupts = <a 4 b 4 c 4 d 4 e 4>;
+ interrupts = <b 4 c 4 a 4 d 4 e 4>;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
- interrupts = <9 4 f 4>;
+ interrupts = <f 4 9 4>;
reg = <ef600800 70>;
mal-device = <&MAL>;
mal-tx-channel = <0 1>;
^ permalink raw reply
* Re: PPC405GP Walnut irq patch
From: Steven A. Falco @ 2007-10-30 21:41 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <47279CF0.4050600@harris.com>
[-- Attachment #1: Type: text/plain, Size: 628 bytes --]
I realized that I should have done this from the root level. So here is
the corrected patch.
Signed-off-by: Steve Falco <sfalco at harris.com>
Steven A. Falco wrote:
> Hi - I have found a bug in the ARCH=powerpc Walnut BSP. The order of
> the ethernet interrupts in the walnut.dts file doesn't match the
> documentation. I discovered this when porting the BSP to a custom
> board - the ethernet would not work. The attached patch corrects that.
>
> This is the first patch I am submitting, so please advise me if there
> is anything I should do differently.
>
> Signed-off-by: Steve Falco <sfalco at harris.com>
>
>
[-- Attachment #2: irq.patch --]
[-- Type: text/x-patch, Size: 660 bytes --]
diff --git a/arch/powerpc/boot/dts/walnut.dts b/arch/powerpc/boot/dts/walnut.dts
index 27bef06..dd65115 100644
--- a/arch/powerpc/boot/dts/walnut.dts
+++ b/arch/powerpc/boot/dts/walnut.dts
@@ -67,7 +67,7 @@
num-tx-chans = <2>;
num-rx-chans = <1>;
interrupt-parent = <&UIC0>;
- interrupts = <a 4 b 4 c 4 d 4 e 4>;
+ interrupts = <b 4 c 4 a 4 d 4 e 4>;
};
POB0: opb {
@@ -117,7 +117,7 @@
device_type = "network";
compatible = "ibm,emac-405gp", "ibm,emac";
interrupt-parent = <&UIC0>;
- interrupts = <9 4 f 4>;
+ interrupts = <f 4 9 4>;
reg = <ef600800 70>;
mal-device = <&MAL>;
mal-tx-channel = <0 1>;
^ permalink raw reply related
* [PATCH] [powerpc v2] update xmon slb code
From: Will Schmidt @ 2007-10-30 21:50 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
[powerpc] update xmon slb code
This adds a bit more detail to the xmon SLB output. When the valid bit is
set, This displays the ESID and VSID values, as well as decoding the
segment size. (1T or 256M). This supresses the output for any slb entries
that contain only zeros.
sample output from power6 (1T segment support):
00 c000000008000000 40004f7ca3000500 1T ESID= c00000 VSID=40004f7ca3 LLP bits:100
01 d000000008000000 4000eb71b0000400 1T ESID= d00000 VSID=4000eb71b0 LLP bits: 0
03 0000000008000000 0000628021c6ac80 256M ESID= 0 VSID= 628021c6a LLP bits: 0
04 00000f0008000000 400095c1e8000c80 1T ESID= f VSID=400095c1e8 LLP bits: 0
22 cf00000008000000 400011b260000500 1T ESID= cf0000 VSID=400011b260 LLP bits:100
62 0000040008000000 40005d488d000c80 1T ESID= 4 VSID=40005d488d LLP bits: 0
63 0000000018000000 0000633f90285c80 256M ESID= 1 VSID= 633f90285 LLP bits: 0
sample output from power5 (notice the non-valid but non-zero entries)
00 c000000008000000 0000408f92c94500 256M ESID=c00000000 VSID= 408f92c94 LLP bits:100
01 d000000008000000 0000f09b89af5400 256M ESID=d00000000 VSID= f09b89af5 LLP bits: 0
03 0000000010000000 0000136eafb0bc80
11 0000000008000000 00005928811f2c80 256M ESID= 0 VSID= 5928811f2 LLP bits: 0
12 00000000f8000000 0000645ff8d87c80 256M ESID= f VSID= 645ff8d87 LLP bits: 0
13 0000000048000000 00005c263aa5ec80 256M ESID= 4 VSID= 5c263aa5e LLP bits: 0
14 0000000018000000 000059e7ef80dc80 256M ESID= 1 VSID= 59e7ef80d LLP bits: 0
15 0000000010000000 000059e7ef80dc80
Tested on power5 and power6.
Signed-Off-By: Will Schmidt <will_schmidt@vnet.ibm.com>
---
This version adds padding around the ESID and VSID fields, and the LLP bits
are displayed too. (Per request from Olof and Ben).
I'll try to follow up sometime later with code that will handle decoding page
sizes. I dont have a testcase handy to properly exercise that yet. :-)
---
arch/powerpc/xmon/xmon.c | 27 +++++++++++++++++++++------
1 files changed, 21 insertions(+), 6 deletions(-)
diff --git a/arch/powerpc/xmon/xmon.c b/arch/powerpc/xmon/xmon.c
index 121b04d..93c26c3 100644
--- a/arch/powerpc/xmon/xmon.c
+++ b/arch/powerpc/xmon/xmon.c
@@ -2527,16 +2527,31 @@ static void xmon_print_symbol(unsigned long address, const char *mid,
static void dump_slb(void)
{
int i;
- unsigned long tmp;
+ unsigned long esid,vsid,valid;
+ unsigned long llp_bits;
printf("SLB contents of cpu %x\n", smp_processor_id());
for (i = 0; i < SLB_NUM_ENTRIES; i++) {
- asm volatile("slbmfee %0,%1" : "=r" (tmp) : "r" (i));
- printf("%02d %016lx ", i, tmp);
-
- asm volatile("slbmfev %0,%1" : "=r" (tmp) : "r" (i));
- printf("%016lx\n", tmp);
+ asm volatile("slbmfee %0,%1" : "=r" (esid) : "r" (i));
+ asm volatile("slbmfev %0,%1" : "=r" (vsid) : "r" (i));
+ valid = (esid & SLB_ESID_V);
+ if (valid | esid | vsid) {
+ printf("%02d %016lx %016lx", i, esid, vsid);
+ if (valid) {
+ llp_bits = vsid & SLB_VSID_LLP;
+ if (vsid & SLB_VSID_B_1T) {
+ printf(" 1T ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
+ GET_ESID_1T(esid),vsid >> SLB_VSID_SHIFT_1T,
+ llp_bits);
+ } else {
+ printf(" 256M ESID=%9lx VSID=%10lx LLP bits:%3lx \n",
+ GET_ESID(esid),vsid >> SLB_VSID_SHIFT,
+ llp_bits);
+ }
+ } else
+ printf("\n");
+ }
}
}
^ permalink raw reply related
* Re: [PATCH] ehea: add kexec support
From: Michael Ellerman @ 2007-10-30 22:50 UTC (permalink / raw)
To: Christoph Raisch
Cc: Thomas Q Klein, ossthema, Jeff Garzik, Jan-Bernd Themann, netdev,
linux-kernel, linux-ppc, Marcus Eder, Stefan Roscher
In-Reply-To: <OF79E7ACE7.5D0488CE-ONC1257384.002E58C0-C1257384.002F8561@de.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 957 bytes --]
On Tue, 2007-10-30 at 09:39 +0100, Christoph Raisch wrote:
>
> Michael Ellerman <michael@ellerman.id.au> wrote on 28.10.2007 23:32:17:
> >
> >
> > How do you plan to support kdump?
> >
>
> When kexec is fully supported kdump should work out of the box
> as for any other ethernet card (if you load the right eth driver).
> There's nothing specific to kdump you have to handle in
> ethernet device drivers.
> Hope I didn't miss anything here...
Perhaps. When we kdump the kernel does not call the reboot notifiers, so
the code Jan-Bernd just added won't get called. So the eHEA resources
won't be freed. When the kdump kernel tries to load the eHEA driver what
will happen?
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: RFC: replace device_type with new "class" property?
From: David Gibson @ 2007-10-30 22:58 UTC (permalink / raw)
To: Yoder Stuart-B08248; +Cc: Olof Johansson, linuxppc-dev
In-Reply-To: <9696D7A991D0824DBA8DFAC74A9C5FA3035F278B@az33exm25.fsl.freescale.net>
On Tue, Oct 30, 2007 at 09:23:14AM -0700, Yoder Stuart-B08248 wrote:
>
> > Explicitly specifying what device class bindings / conventions the
> > node complies with is cute, but not actually all that useful in
> > practice. If it looks like a "duck" class device node, and it
> > quacks^Whas the properties of a "duck" class device node, it's "duck"
> > class compliant.
>
> Don't know how cute it is, but I think it is practically
> helpful. Take another example:
>
> Say you-- a human reader-- see this in a device
> tree:
>
> ...
> interrupts = <b 8>;
> interrupt-parent = < &mpic >;
> ...
>
> What does the 'b' and '8' mean? You look
> at the interrupt controller node--
>
> mpic: pic@40000 {
> clock-frequency = <0>;
> interrupt-controller;
> #address-cells = <0>;
> #interrupt-cells = <2>;
> reg = <40000 40000>;
> compatible = "fsl,xyz";
> big-endian;
> }
>
> Note-- I removed the device_type property and changed
> compatible somewhat. How are you going to find where
> the meaning interrupt controller's interrupt cells are
> defined? What spec will you look at?
>
> device_type = "open-pic"; makes it perfectly clear.
> It's an open-pic type controller and follows that
> binding.
That's an extremely contrived example - it only works because for
historical reasons the "open-pic" device_type describes a programming
model as well as an OF method interface. In general, you always need
to look at a node's "compatible" and the binding for that to work out
what it's properties mean, or if it's an interrupt controller what the
format of its interrupt specifiers is.
open-pic is the *only* example I can think of where device_type will
tell you this. In fact, "open-pic" really belongs in compatible.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox