* [PATCH 4/6] ehea: header files
From: Jan-Bernd Themann @ 2006-08-09 8:39 UTC (permalink / raw)
To: netdev; +Cc: Thomas Klein, linux-ppc, Christoph Raisch, linux-kernel,
Marcus Eder
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
drivers/net/ehea/ehea.h | 452 +++++++++++++++++++++++++++++++++++++++++++++
drivers/net/ehea/ehea_hw.h | 319 +++++++++++++++++++++++++++++++
2 files changed, 771 insertions(+)
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea.h 1969-12-31 16:00:00.000000000 -0800
+++ kernel/drivers/net/ehea/ehea.h 2006-08-08 23:59:39.927452928 -0700
@@ -0,0 +1,452 @@
+/*
+ * linux/drivers/net/ehea/ehea.h
+ *
+ * eHEA ethernet device driver for IBM eServer System p
+ *
+ * (C) Copyright IBM Corp. 2006
+ *
+ * Authors:
+ * Christoph Raisch <raisch@de.ibm.com>
+ * Jan-Bernd Themann <themann@de.ibm.com>
+ * Heiko-Joerg Schick <schickhj@de.ibm.com>
+ * Thomas Klein <tklein@de.ibm.com>
+ *
+ *
+ * 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, 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __EHEA_H__
+#define __EHEA_H__
+
+#include <linux/version.h>
+#include <linux/module.h>
+#include <linux/moduleparam.h>
+#include <linux/kernel.h>
+#include <linux/vmalloc.h>
+#include <linux/mm.h>
+#include <linux/slab.h>
+#include <linux/sched.h>
+#include <linux/err.h>
+#include <linux/list.h>
+#include <linux/netdevice.h>
+#include <linux/etherdevice.h>
+#include <linux/kthread.h>
+#include <linux/ethtool.h>
+#include <linux/if_vlan.h>
+#include <asm/ibmebus.h>
+#include <asm/of_device.h>
+#include <asm/abs_addr.h>
+#include <asm/semaphore.h>
+#include <asm/current.h>
+#include <asm/io.h>
+
+#define EHEA_DRIVER_NAME "IBM eHEA"
+#define EHEA_DRIVER_VERSION "EHEA_0015"
+
+#define NET_IP_ALIGN 0
+#define EHEA_NUM_TX_QP 1
+#ifdef EHEA_SMALL_QUEUES
+#define EHEA_MAX_CQE_COUNT 1020
+#define EHEA_MAX_ENTRIES_SQ 1020
+#define EHEA_MAX_ENTRIES_RQ1 4080
+#define EHEA_MAX_ENTRIES_RQ2 1020
+#define EHEA_MAX_ENTRIES_RQ3 1020
+#define EHEA_SWQE_REFILL_TH 100
+#else
+#define EHEA_MAX_CQE_COUNT 32000
+#define EHEA_MAX_ENTRIES_SQ 16000
+#define EHEA_MAX_ENTRIES_RQ1 32080
+#define EHEA_MAX_ENTRIES_RQ2 4020
+#define EHEA_MAX_ENTRIES_RQ3 4020
+#define EHEA_SWQE_REFILL_TH 1000
+#endif
+
+#define EHEA_MAX_ENTRIES_EQ 20
+
+#define EHEA_SG_SQ 2
+#define EHEA_SG_RQ1 1
+#define EHEA_SG_RQ2 0
+#define EHEA_SG_RQ3 0
+
+#define EHEA_MAX_PACKET_SIZE 9022 /* for jumbo frame */
+#define EHEA_RQ2_PKT_SIZE 1522
+#define EHEA_LL_PKT_SIZE 256
+
+/* Send completion signaling */
+#define EHEA_SIG_IV 1000
+#define EHEA_SIG_IV_LONG 4
+
+/* Protection Domain Identifier */
+#define EHEA_PD_ID 0xaabcdeff
+
+#define EHEA_RQ2_THRESHOLD 1
+/* use RQ3 threshold of 1522 bytes */
+#define EHEA_RQ3_THRESHOLD 9
+
+#define EHEA_SPEED_10G 10000
+#define EHEA_SPEED_1G 1000
+#define EHEA_SPEED_100M 100
+#define EHEA_SPEED_10M 10
+
+/* Broadcast/Multicast registration types */
+#define EHEA_BCMC_SCOPE_ALL 0x08
+#define EHEA_BCMC_SCOPE_SINGLE 0x00
+#define EHEA_BCMC_MULTICAST 0x04
+#define EHEA_BCMC_BROADCAST 0x00
+#define EHEA_BCMC_UNTAGGED 0x02
+#define EHEA_BCMC_TAGGED 0x00
+#define EHEA_BCMC_VLANID_ALL 0x01
+#define EHEA_BCMC_VLANID_SINGLE 0x00
+
+/* Use this define to kmallocate PHYP control blocks */
+#define H_CB_ALIGNMENT 4096
+
+#define EHEA_PAGESHIFT 12
+#define EHEA_PAGESIZE 4096UL
+#define EHEA_CACHE_LINE 128
+
+#define EHEA_ENABLE 1
+#define EHEA_DISABLE 0
+
+/* Memory Regions */
+#define EHEA_MR_MAX_TX_PAGES 20
+#define EHEA_MR_TX_DATA_PN 3
+#define EHEA_MR_ACC_CTRL 0x00800000
+#define EHEA_RWQES_PER_MR_RQ2 10
+#define EHEA_RWQES_PER_MR_RQ3 10
+
+
+void ehea_set_ethtool_ops(struct net_device *netdev);
+
+#ifndef KEEP_EDEBS_BELOW
+#define KEEP_EDEBS_BELOW 8
+#endif
+
+extern int ehea_trace_level;
+
+#ifdef EHEA_NO_EDEB
+#define EDEB_P_GENERIC(level, idstring, format, args...) \
+ while (0 == 1) { \
+ if(unlikely (level <= ehea_trace_level)) { \
+ printk("%s " idstring " "format "\n", \
+ __func__, ##args); \
+ } \
+ } \
+
+#else
+
+#define EDEB_P_GENERIC(level,idstring,format,args...) \
+if (level < KEEP_EDEBS_BELOW) { \
+ do { \
+ if(unlikely (level <= ehea_trace_level)) { \
+ printk("%s " idstring " "format "\n", \
+ __func__, ##args); \
+ } \
+ } while (1 == 0); \
+}
+#endif
+
+#define EDEB(level, format, args...) \
+ EDEB_P_GENERIC(level, "", format, ##args)
+
+#define EDEB_ERR(level, format, args...) \
+ EDEB_P_GENERIC(level, "EHEA_ERROR", format, ##args)
+
+#define EDEB_EN(level, format, args...) \
+ EDEB_P_GENERIC(level, ">>>", format, ##args)
+
+#define EDEB_EX(level, format, args...) \
+ EDEB_P_GENERIC(level, "<<<", format, ##args)
+
+#define EHEA_BMASK(pos, length) (((pos) << 16) + (length))
+#define EHEA_BMASK_IBM(from, to) (((63 - to) << 16) + ((to) - (from) + 1))
+#define EHEA_BMASK_SHIFTPOS(mask) (((mask) >> 16) & 0xffff)
+#define EHEA_BMASK_MASK(mask) \
+ (0xffffffffffffffffULL >> ((64 - (mask)) & 0xffff))
+#define EHEA_BMASK_SET(mask, value) \
+ ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
+#define EHEA_BMASK_GET(mask, value) \
+ (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
+
+extern void exit(int);
+
+#define EDEB_DMP(level, adr, len, format, args...) \
+if (level < KEEP_EDEBS_BELOW) { \
+ if(unlikely (level <= ehea_trace_level)) { \
+ do { \
+ unsigned int x; \
+ unsigned int l = (unsigned int)(len); \
+ unsigned char *deb = (unsigned char*)(adr); \
+ for (x = 0; x < l; x += 16) { \
+ EDEB(level, format " adr=%p ofs=%04x %016lx %016lx", \
+ ##args, deb, x, *((u64 *)&deb[0]), \
+ *((u64 *)&deb[8])); \
+ deb += 16; \
+ } \
+ } while (0); \
+ } \
+}
+
+
+/*
+ * struct generic ehea page
+ */
+struct ipz_page {
+ u8 entries[PAGE_SIZE];
+};
+
+/*
+ * struct generic queue in linux kernel virtual memory
+ */
+struct ipz_queue {
+ u64 current_q_offset; /* current queue entry */
+ struct ipz_page **queue_pages; /* array of pages belonging to queue */
+ u32 qe_size; /* queue entry size */
+ u32 act_nr_of_sg;
+ u32 queue_length; /* queue length allocated in bytes */
+ u32 pagesize;
+ u32 toggle_state; /* toggle flag - per page */
+ u32 reserved; /* 64 bit alignment */
+};
+
+
+/*
+ * h_galpa:
+ * for pSeries this is a 64bit memory address where
+ * I/O memory is mapped into CPU address space
+ */
+
+struct h_galpa {
+ u64 fw_handle;
+};
+
+struct h_galpas {
+ struct h_galpa kernel; /* kernel space accessible resource,
+ set to 0 if unused */
+ struct h_galpa user; /* user space accessible resource
+ set to 0 if unused */
+ u32 pid; /* PID of userspace galpa checking */
+};
+
+struct ehea_qp;
+struct ehea_cq;
+struct ehea_eq;
+struct ehea_port;
+struct ehea_av;
+
+struct ehea_qp_init_attr {
+ /* input parameter */
+ u32 qp_token;
+ u8 low_lat_rq1;
+ u8 signalingtype;
+ u8 rq_count;
+ u8 eqe_gen;
+ u16 max_nr_send_wqes;
+ u16 max_nr_rwqes_rq1;
+ u16 max_nr_rwqes_rq2;
+ u16 max_nr_rwqes_rq3;
+ u8 wqe_size_enc_sq;
+ u8 wqe_size_enc_rq1;
+ u8 wqe_size_enc_rq2;
+ u8 wqe_size_enc_rq3;
+ u8 swqe_imm_data_len;
+ u16 port_nr;
+ u16 rq2_threshold;
+ u16 rq3_threshold;
+ u64 send_cq_handle;
+ u64 recv_cq_handle;
+ u64 aff_eq_handle;
+
+ /* output parameter */
+ u32 qp_nr;
+ u16 act_nr_send_wqes;
+ u16 act_nr_rwqes_rq1;
+ u16 act_nr_rwqes_rq2;
+ u16 act_nr_rwqes_rq3;
+ u8 act_wqe_size_enc_sq;
+ u8 act_wqe_size_enc_rq1;
+ u8 act_wqe_size_enc_rq2;
+ u8 act_wqe_size_enc_rq3;
+ u32 nr_sq_pages;
+ u32 nr_rq1_pages;
+ u32 nr_rq2_pages;
+ u32 nr_rq3_pages;
+ u32 liobn_sq;
+ u32 liobn_rq1;
+ u32 liobn_rq2;
+ u32 liobn_rq3;
+};
+
+struct ehea_eq_attr {
+ u32 type;
+ u32 max_nr_of_eqes;
+ u8 eqe_gen;
+ u64 eq_handle;
+ u32 act_nr_of_eqes;
+ u32 nr_pages;
+ u32 ist1;
+ u32 ist2;
+ u32 ist3;
+ u32 ist4;
+};
+
+struct ehea_eq {
+ struct ehea_adapter *adapter;
+ struct ipz_queue ipz_queue;
+ u64 ipz_eq_handle;
+ struct h_galpas galpas;
+ spinlock_t spinlock;
+ struct ehea_eq_attr attr;
+};
+
+struct ehea_qp {
+ struct ehea_adapter *adapter;
+ u64 ipz_qp_handle; /* QP handle for h-calls */
+ struct ipz_queue ipz_squeue;
+ struct ipz_queue ipz_rqueue1;
+ struct ipz_queue ipz_rqueue2;
+ struct ipz_queue ipz_rqueue3;
+ struct h_galpas galpas;
+ struct ehea_qp_init_attr init_attr;
+};
+
+struct ehea_cq_attr {
+ /* input parameter */
+ u32 max_nr_of_cqes;
+ u32 cq_token;
+ u64 eq_handle;
+
+ /* output parameter */
+ u32 act_nr_of_cqes;
+ u32 nr_pages;
+};
+
+struct ehea_cq {
+ struct ehea_adapter *adapter;
+ u64 ipz_cq_handle;
+ struct ipz_queue ipz_queue;
+ struct h_galpas galpas;
+ struct ehea_cq_attr attr;
+};
+
+struct ehea_mr {
+ u64 handle;
+ u64 vaddr;
+ u32 lkey;
+};
+
+struct port_state {
+ int poll_max_processed;
+ int poll_receive_errors;
+ int ehea_poll;
+ int queue_stopped;
+ int min_swqe_avail;
+ u64 sqc_stop_sum;
+ int pkt_send;
+ int pkt_xmit;
+ int send_tasklet;
+ int nwqe;
+};
+
+#define EHEA_IRQ_NAME_SIZE 20
+struct ehea_port_res {
+ struct ehea_mr send_mr;
+ struct ehea_mr recv_mr;
+ spinlock_t xmit_lock;
+ struct ehea_port *port;
+ char int_recv_name[EHEA_IRQ_NAME_SIZE];
+ char int_send_name[EHEA_IRQ_NAME_SIZE];
+ struct ehea_qp *qp;
+ struct ehea_cq *send_cq;
+ struct ehea_cq *recv_cq;
+ struct ehea_eq *send_eq;
+ struct ehea_eq *recv_eq;
+ spinlock_t send_lock;
+ struct sk_buff **skb_arr_rq1;
+ struct sk_buff **skb_arr_rq2;
+ struct sk_buff **skb_arr_rq3;
+ struct sk_buff **skb_arr_sq;
+ int skb_arr_rq1_len;
+ int skb_arr_rq2_len;
+ int skb_arr_rq3_len;
+ int skb_arr_sq_len;
+ int skb_rq2_index;
+ int skb_rq3_index;
+ int skb_sq_index;
+ spinlock_t netif_queue;
+ atomic_t swqe_avail;
+ int swqe_ll_count;
+ int swqe_count;
+ u32 swqe_id_counter;
+ u64 tx_packets;
+ struct tasklet_struct send_comp_task;
+ spinlock_t recv_lock;
+ struct timer_list timer; /* polling mode, no interrupts */
+ struct timer_list skb_timer; /* skb cleanup timer */
+ struct port_state p_state;
+ u64 rx_packets;
+ u32 poll_counter;
+};
+
+
+struct ehea_adapter {
+ u64 handle;
+ u8 num_ports;
+ struct ehea_port *port[16];
+ struct ehea_eq *neq;
+ struct tasklet_struct neq_tasklet;
+ struct ehea_mr mr;
+ u32 pd;
+ u64 max_mc_mac;
+};
+
+
+struct ehea_mc_list {
+ struct list_head list;
+ u64 macaddr;
+};
+
+#define EHEA_MAX_PORT_RES 16
+struct ehea_port {
+ struct ehea_adapter *adapter; /* adapter that owns this port */
+ struct net_device *netdev;
+ struct net_device_stats stats;
+ struct ehea_port_res port_res[EHEA_MAX_PORT_RES];
+ struct device_node *of_dev_node; /* Open Firmware Device Node */
+ struct ehea_mc_list *mc_list; /* Multicast MAC addresses */
+ struct vlan_group *vgrp;
+ struct ehea_eq *qp_eq;
+ char int_aff_name[EHEA_IRQ_NAME_SIZE];
+ int allmulti; /* Indicates IFF_ALLMULTI state */
+ int promisc; /* Indicates IFF_PROMISC state */
+ int kernel_l_key;
+ int num_tx_qps;
+ u64 mac_addr;
+ u32 logical_port_id;
+ u32 port_speed;
+ u8 full_duplex;
+ u8 num_def_qps;
+};
+
+struct port_res_cfg {
+ int max_entries_rcq;
+ int max_entries_scq;
+ int max_entries_sq;
+ int max_entries_rq1;
+ int max_entries_rq2;
+ int max_entries_rq3;
+};
+
+#endif /* __EHEA_H__ */
--- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_hw.h 1969-12-31 16:00:00.000000000 -0800
+++ kernel/drivers/net/ehea/ehea_hw.h 2006-08-08 23:59:38.086466760 -0700
@@ -0,0 +1,319 @@
+/*
+ * linux/drivers/net/ehea/ehea_hw.h
+ *
+ * eHEA ethernet device driver for IBM eServer System p
+ *
+ * (C) Copyright IBM Corp. 2006
+ *
+ * Authors:
+ * Christoph Raisch <raisch@de.ibm.com>
+ * Jan-Bernd Themann <themann@de.ibm.com>
+ * Heiko-Joerg Schick <schickhj@de.ibm.com>
+ * Thomas Klein <tklein@de.ibm.com>
+ *
+ *
+ * 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, 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., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#ifndef __EHEA_HW_H__
+#define __EHEA_HW_H__
+
+#define QPX_SQA_VALUE EHEA_BMASK_IBM(48,63)
+#define QPX_RQ1A_VALUE EHEA_BMASK_IBM(48,63)
+#define QPX_RQ2A_VALUE EHEA_BMASK_IBM(48,63)
+#define QPX_RQ3A_VALUE EHEA_BMASK_IBM(48,63)
+
+#define QPTEMM_OFFSET(x) offsetof(struct ehea_qptemm, x)
+
+struct ehea_qptemm {
+ u64 qpx_hcr;
+ u64 qpx_c;
+ u64 qpx_herr;
+ u64 qpx_aer;
+ u64 qpx_sqa;
+ u64 qpx_sqc;
+ u64 qpx_rq1a;
+ u64 qpx_rq1c;
+ u64 qpx_st;
+ u64 qpx_aerr;
+ u64 qpx_tenure;
+ u64 qpx_reserved1[(0x098 - 0x058) / 8];
+ u64 qpx_portp;
+ u64 qpx_reserved2[(0x100 - 0x0A0) / 8];
+ u64 qpx_t;
+ u64 qpx_sqhp;
+ u64 qpx_sqptp;
+ u64 qpx_reserved3[(0x140 - 0x118) / 8];
+ u64 qpx_sqwsize;
+ u64 qpx_reserved4[(0x170 - 0x148) / 8];
+ u64 qpx_sqsize;
+ u64 qpx_reserved5[(0x1B0 - 0x178) / 8];
+ u64 qpx_sigt;
+ u64 qpx_wqecnt;
+ u64 qpx_rq1hp;
+ u64 qpx_rq1ptp;
+ u64 qpx_rq1size;
+ u64 qpx_reserved6[(0x220 - 0x1D8) / 8];
+ u64 qpx_rq1wsize;
+ u64 qpx_reserved7[(0x240 - 0x228) / 8];
+ u64 qpx_pd;
+ u64 qpx_scqn;
+ u64 qpx_rcqn;
+ u64 qpx_aeqn;
+ u64 reserved49;
+ u64 qpx_ram;
+ u64 qpx_reserved8[(0x300 - 0x270) / 8];
+ u64 qpx_rq2a;
+ u64 qpx_rq2c;
+ u64 qpx_rq2hp;
+ u64 qpx_rq2ptp;
+ u64 qpx_rq2size;
+ u64 qpx_rq2wsize;
+ u64 qpx_rq2th;
+ u64 qpx_rq3a;
+ u64 qpx_rq3c;
+ u64 qpx_rq3hp;
+ u64 qpx_rq3ptp;
+ u64 qpx_rq3size;
+ u64 qpx_rq3wsize;
+ u64 qpx_rq3th;
+ u64 qpx_lpn;
+ u64 qpx_reserved9[(0x400 - 0x378) / 8];
+ u64 reserved_ext[(0x500 - 0x400) / 8];
+ u64 reserved2[(0x1000 - 0x500) / 8];
+};
+
+#define MRx_HCR_LPARID_VALID EHEA_BMASK_IBM(0, 0)
+
+#define MRMWMM_OFFSET(x) offsetof(struct ehea_mrmwmm, x)
+
+struct ehea_mrmwmm {
+ u64 mrx_hcr;
+ u64 mrx_c;
+ u64 mrx_herr;
+ u64 mrx_aer;
+ u64 mrx_pp;
+ u64 reserved1;
+ u64 reserved2;
+ u64 reserved3;
+ u64 reserved4[(0x200 - 0x40) / 8];
+ u64 mrx_ctl[64];
+};
+
+#define QPEDMM_OFFSET(x) offsetof(struct ehea_qpedmm, x)
+
+struct ehea_qpedmm {
+
+ u64 reserved0[(0x400) / 8];
+ u64 qpedx_phh;
+ u64 qpedx_ppsgp;
+ u64 qpedx_ppsgu;
+ u64 qpedx_ppdgp;
+ u64 qpedx_ppdgu;
+ u64 qpedx_aph;
+ u64 qpedx_apsgp;
+ u64 qpedx_apsgu;
+ u64 qpedx_apdgp;
+ u64 qpedx_apdgu;
+ u64 qpedx_apav;
+ u64 qpedx_apsav;
+ u64 qpedx_hcr;
+ u64 reserved1[4];
+ u64 qpedx_rrl0;
+ u64 qpedx_rrrkey0;
+ u64 qpedx_rrva0;
+ u64 reserved2;
+ u64 qpedx_rrl1;
+ u64 qpedx_rrrkey1;
+ u64 qpedx_rrva1;
+ u64 reserved3;
+ u64 qpedx_rrl2;
+ u64 qpedx_rrrkey2;
+ u64 qpedx_rrva2;
+ u64 reserved4;
+ u64 qpedx_rrl3;
+ u64 qpedx_rrrkey3;
+ u64 qpedx_rrva3;
+};
+
+#define CQX_FECADDER EHEA_BMASK_IBM(32, 63)
+#define CQX_FEC_CQE_CNT EHEA_BMASK_IBM(32, 63)
+#define CQX_N1_GENERATE_COMP_EVENT EHEA_BMASK_IBM(0, 0)
+#define CQX_EP_EVENT_PENDING EHEA_BMASK_IBM(0, 0)
+
+#define CQTEMM_OFFSET(x) offsetof(struct ehea_cqtemm, x)
+
+struct ehea_cqtemm {
+ u64 cqx_hcr;
+ u64 cqx_c;
+ u64 cqx_herr;
+ u64 cqx_aer;
+ u64 cqx_ptp;
+ u64 cqx_tp;
+ u64 cqx_fec;
+ u64 cqx_feca;
+ u64 cqx_ep;
+ u64 cqx_eq;
+ u64 reserved1;
+ u64 cqx_n0;
+ u64 cqx_n1;
+ u64 reserved2[(0x1000 - 0x60) / 8];
+};
+
+#define EQTEMM_OFFSET(x) offsetof(struct ehea_eqtemm, x)
+
+struct ehea_eqtemm {
+ u64 EQx_HCR;
+ u64 EQx_C;
+ u64 EQx_HERR;
+ u64 EQx_AER;
+ u64 EQx_PTP;
+ u64 EQx_TP;
+ u64 EQx_SSBA;
+ u64 EQx_PSBA;
+ u64 EQx_CEC;
+ u64 EQx_MEQL;
+ u64 EQx_XISBI;
+ u64 EQx_XISC;
+ u64 EQx_IT;
+};
+
+static inline u64 hipz_galpa_load(struct h_galpa galpa, u32 offset)
+{
+ u64 addr = galpa.fw_handle + offset;
+ u64 out;
+ EDEB_EN(7, "addr=%lx offset=%x ", addr, offset);
+ out = *(volatile u64 *)addr;
+ EDEB_EX(7, "addr=%lx value=%lx", addr, out);
+ return out;
+};
+
+static inline void hipz_galpa_store(struct h_galpa galpa, u32 offset, u64 value)
+{
+ u64 addr = galpa.fw_handle + offset;
+ EDEB_EN(7, "addr=%lx offset=%x value=%lx", addr, offset,
+ value);
+ *(u64 *) addr = value;
+ hipz_galpa_load(galpa, offset); /* synchronize explicitly to ehea */
+ EDEB_EX(7, "");
+};
+
+static inline void hipz_galpa_store_acc(struct h_galpa galpa, u32 offset,
+ u64 value)
+{
+ u64 addr = galpa.fw_handle + offset;
+ EDEB(7, "Accelerated store: addr=%lx offset=%x value=%lx",
+ addr, offset, value);
+ *(u64 *) addr = value;
+};
+
+#define hipz_galpa_store_eq(gal, offset, value)\
+ hipz_galpa_store(gal, EQTEMM_OFFSET(offset), value)
+#define hipz_galpa_load_eq(gal, offset)\
+ hipz_galpa_load(gal, EQTEMM_OFFSET(offset))
+
+#define hipz_galpa_store_cq(gal, offset, value)\
+ hipz_galpa_store(gal, CQTEMM_OFFSET(offset), value)
+#define hipz_galpa_load_cq(gal, offset)\
+ hipz_galpa_load(gal, CQTEMM_OFFSET(offset))
+
+#define hipz_galpa_store_qp(gal, offset, value)\
+ hipz_galpa_store(gal, QPTEMM_OFFSET(offset), value)
+#define hipz_galpa_load_qp(gal, offset)\
+ hipz_galpa_load(gal, QPTEMM_OFFSET(offset))
+
+#define hipz_galpa_store_qped(gal, offset, value)\
+ hipz_galpa_store(gal, QPEDMM_OFFSET(offset), value)
+#define hipz_galpa_load_qped(gal, offset)\
+ hipz_galpa_load(gal, QPEDMM_OFFSET(offset))
+
+#define hipz_galpa_store_mrmw(gal, offset, value)\
+ hipz_galpa_store(gal, MRMWMM_OFFSET(offset), value)
+#define hipz_galpa_load_mrmw(gal, offset)\
+ hipz_galpa_load(gal, MRMWMM_OFFSET(offset))
+
+#define hipz_galpa_store_base(gal, offset, value)\
+ hipz_galpa_store(gal, HCAGR_OFFSET(offset), value)
+#define hipz_galpa_load_base(gal, offset)\
+ hipz_galpa_load(gal, HCAGR_OFFSET(offset))
+
+static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
+{
+ struct h_galpa gal = qp->galpas.kernel;
+ EDEB_EN(7, "qp=%p, nr_wqes=%d", qp, nr_wqes);
+
+ hipz_galpa_store_acc(gal, QPTEMM_OFFSET(qpx_sqa),
+ EHEA_BMASK_SET(QPX_SQA_VALUE, nr_wqes));
+ EDEB_EX(7, "qpx_sqa = %i", nr_wqes);
+}
+
+static inline void ehea_update_rq3a(struct ehea_qp *qp, u16 nr_wqes)
+{
+ struct h_galpa gal = qp->galpas.kernel;
+ EDEB_EN(7, "ehea_qp=%p, nr_wqes=%d", qp, nr_wqes);
+ hipz_galpa_store_acc(gal, QPTEMM_OFFSET(qpx_rq3a),
+ EHEA_BMASK_SET(QPX_RQ1A_VALUE, nr_wqes));
+ EDEB_EX(7, "QPx_RQA = %i", nr_wqes);
+}
+
+static inline void ehea_update_rq2a(struct ehea_qp *qp, u16 nr_wqes)
+{
+ struct h_galpa gal = qp->galpas.kernel;
+ EDEB_EN(7, "ehea_qp=%p, nr_wqes=%d", qp, nr_wqes);
+ hipz_galpa_store_acc(gal, QPTEMM_OFFSET(qpx_rq2a),
+ EHEA_BMASK_SET(QPX_RQ1A_VALUE, nr_wqes));
+ EDEB_EX(7, "QPx_RQA = %i", nr_wqes);
+}
+
+static inline void ehea_update_rq1a(struct ehea_qp *qp, u16 nr_wqes)
+{
+ struct h_galpa gal = qp->galpas.kernel;
+ EDEB_EN(7, "ehea_qp=%p, nr_wqes=%d", qp, nr_wqes);
+ hipz_galpa_store_acc(gal, QPTEMM_OFFSET(qpx_rq1a),
+ EHEA_BMASK_SET(QPX_RQ1A_VALUE, nr_wqes));
+ EDEB_EX(7, "QPx_RQA = %i", nr_wqes);
+}
+
+static inline void ehea_update_feca(struct ehea_cq *cq, u32 nr_cqes)
+{
+ struct h_galpa gal = cq->galpas.kernel;
+ EDEB_EN(7, "");
+ hipz_galpa_store_acc(gal, CQTEMM_OFFSET(cqx_feca),
+ EHEA_BMASK_SET(CQX_FECADDER, nr_cqes));
+ EDEB_EX(7, "cqx_feca = %i", nr_cqes);
+}
+
+static inline void ehea_reset_cq_n1(struct ehea_cq *cq)
+{
+ struct h_galpa gal = cq->galpas.kernel;
+ EDEB_EN(7, "");
+ hipz_galpa_store_cq(gal,
+ cqx_n1,
+ EHEA_BMASK_SET(CQX_N1_GENERATE_COMP_EVENT, 1));
+ EDEB_EX(7, "");
+}
+
+static inline void ehea_reset_cq_ep(struct ehea_cq *my_cq)
+{
+ struct h_galpa gal = my_cq->galpas.kernel;
+ EDEB_EN(7, "");
+ hipz_galpa_store_acc(gal,
+ CQTEMM_OFFSET(cqx_ep),
+ EHEA_BMASK_SET(CQX_EP_EVENT_PENDING, 0));
+ EDEB_EX(7, "");
+}
+
+
+#endif /* __EHEA_HW_H__ */
^ permalink raw reply
* [PATCH 5/6] ehea: makefile
From: Jan-Bernd Themann @ 2006-08-09 8:40 UTC (permalink / raw)
To: netdev; +Cc: Thomas Klein, linux-ppc, Christoph Raisch, linux-kernel,
Marcus Eder
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
drivers/net/ehea/Makefile | 7 +++++++
1 file changed, 7 insertions(+)
--- linux-2.6.18-rc4-orig/drivers/net/ehea/Makefile 1969-12-31 16:00:00.000000000 -0800
+++ kernel/drivers/net/ehea/Makefile 2006-08-08 23:59:38.083467216 -0700
@@ -0,0 +1,7 @@
+#
+# Makefile for the eHEA ethernet device driver for IBM eServer System p
+#
+
+ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o ehea_phyp.o
+obj-$(CONFIG_EHEA) += ehea_mod.o
+
^ permalink raw reply
* [PATCH 6/6] ehea: Kernel build (Kconfig / Makefile)
From: Jan-Bernd Themann @ 2006-08-09 8:40 UTC (permalink / raw)
To: netdev; +Cc: Thomas Klein, linux-ppc, Christoph Raisch, linux-kernel,
Marcus Eder
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
drivers/net/Kconfig | 6 ++++++
drivers/net/Makefile | 1 +
2 files changed, 7 insertions(+)
diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Kconfig patched_kernel/drivers/net/Kconfig
--- linux-2.6.18-rc4/drivers/net/Kconfig 2006-08-06 11:20:11.000000000 -0700
+++ patched_kernel/drivers/net/Kconfig 2006-08-08 03:00:49.526421944 -0700
@@ -2277,6 +2277,12 @@ config CHELSIO_T1
To compile this driver as a module, choose M here: the module
will be called cxgb.
+config EHEA
+ tristate "eHEA Ethernet support"
+ depends on IBMEBUS
+ ---help---
+ This driver supports the IBM pSeries ethernet adapter
+
config IXGB
tristate "Intel(R) PRO/10GbE support"
depends on PCI
diff -Nurp -X dontdiff linux-2.6.18-rc4/drivers/net/Makefile patched_kernel/drivers/net/Makefile
--- linux-2.6.18-rc4/drivers/net/Makefile 2006-08-06 11:20:11.000000000 -0700
+++ patched_kernel/drivers/net/Makefile 2006-08-08 03:00:30.061451584 -0700
@@ -10,6 +10,7 @@ obj-$(CONFIG_E1000) += e1000/
obj-$(CONFIG_IBM_EMAC) += ibm_emac/
obj-$(CONFIG_IXGB) += ixgb/
obj-$(CONFIG_CHELSIO_T1) += chelsio/
+obj-$(CONFIG_EHEA) += ehea/
obj-$(CONFIG_BONDING) += bonding/
obj-$(CONFIG_GIANFAR) += gianfar_driver.o
^ permalink raw reply
* Re: [PATCH 1/6] ehea: interface to network stack
From: Christian Borntraeger @ 2006-08-09 9:08 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99EFC.3000105@de.ibm.com>
Hi Jan-Bernd,
I had some minutes, here are some finding after a quick look.
On Wednesday 09 August 2006 10:38, you wrote:
> +static struct net_device_stats *ehea_get_stats(struct net_device *dev)
> +{
> + int i;
> + u64 hret =3D H_HARDWARE;
> + u64 rx_packets =3D 0;
> + struct ehea_port *port =3D (struct ehea_port*)dev->priv;
dev->priv is a void pointer, this cast is unnecessary. When we are at it, h=
ave=20
you considered the netdev_priv macro? This will require some prep in=20
alloc_netdev and might not always pe possible.=20
> + struct ehea_adapter *adapter =3D port->adapter;
> + struct hcp_query_ehea_port_cb_2 *cb2 =3D NULL;
> + struct net_device_stats *stats =3D &port->stats;
> +
> + EDEB_EN(7, "net_device=3D%p", dev);
> +
> + cb2 =3D kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
> + if (!cb2) {
> + EDEB_ERR(4, "No memory for cb2");
> + goto get_stat_exit;
> + }
> +
> + hret =3D ehea_h_query_ehea_port(adapter->handle,
> + port->logical_port_id,
> + H_PORT_CB2,
> + H_PORT_CB2_ALL,
> + cb2);
> +
> + if (hret !=3D H_SUCCESS) {
> + EDEB_ERR(4, "query_ehea_port failed for cb2");
> + goto get_stat_exit;
> + }
You leak memory here, dont you? (cb2 points to allocated memory and you are=
in=20
an error path.)
> +
> + EDEB_DMP(7, (u8*)cb2,
> + sizeof(struct hcp_query_ehea_port_cb_2), "After HCALL");
> +
> + for (i =3D 0; i < port->num_def_qps; i++) {
> + rx_packets +=3D port->port_res[i].rx_packets;
> + }
> +
> + stats->tx_packets =3D cb2->txucp + cb2->txmcp + cb2->txbcp;
> + stats->multicast =3D cb2->rxmcp;
> + stats->rx_errors =3D cb2->rxuerr;
> + stats->rx_bytes =3D cb2->rxo;
> + stats->tx_bytes =3D cb2->txo;
> + stats->rx_packets =3D rx_packets;
> +
> +get_stat_exit:
> + EDEB_EX(7, "");
> + return stats;
> +}
again, cb2 is not freed.
[...]
> +static inline u64 get_swqe_addr(u64 tmp_addr, int addr_seg)
> +{
> + u64 addr;
> + addr =3D tmp_addr;
> + return addr;
> +}
This is suppsed to change in the future? If not you can get rid of it.=20
> +
> +static inline u64 get_rwqe_addr(u64 tmp_addr)
> +{
> + return tmp_addr;
> +}
same here.=20
> +
> +static int ehea_poll(struct net_device *dev, int *budget)
> +{
> + struct ehea_port *port =3D (struct ehea_port*)dev->priv;
Again. no cast, maybe netdev_priv macro.=20
> + struct ehea_port_res *port_res =3D &port->port_res[0];
> + struct ehea_cqe *cqe;
> + struct ehea_qp *qp =3D port_res->qp;
> + int wqe_index =3D 0;
> + int last_wqe_index =3D 0;
> + int x =3D 0;
> + int processed =3D 0;
> + int processed_RQ1 =3D 0;
> + int processed_RQ2 =3D 0;
> + int processed_RQ3 =3D 0;
> + int rq;
> + int intreq;
> + struct sk_buff **skb_arr_rq1 =3D port_res->skb_arr_rq1;
> + struct sk_buff **skb_arr_rq2 =3D port_res->skb_arr_rq2;
> + struct sk_buff **skb_arr_rq3 =3D port_res->skb_arr_rq3;
> + int skb_arr_rq1_len =3D port_res->skb_arr_rq1_len;
> + int my_quota =3D min(*budget, dev->quota);
> +
> + EDEB_EN(7, "dev=3D%p, port_res=3D%p, budget=3D%d, quota=3D%d, qp_nr=3D%=
x",
> + dev, port_res, *budget, dev->quota,
> + port_res->qp->init_attr.qp_nr);
> + my_quota =3D min(my_quota, EHEA_MAX_RWQE);
> +
> + /* rq0 is low latency RQ */
> + cqe =3D ehea_poll_rq1(qp, &wqe_index);
> + while ((my_quota > 0) && cqe) {
> + ehea_inc_rq1(qp);
> + processed_RQ1++;
> + processed++;
> + my_quota--;
> +
> + EDEB_DMP(6, (u8*)cqe, 4 * 16, "CQE");
> + last_wqe_index =3D wqe_index;
> + rmb();
> + if (!ehea_check_cqe(cqe, &rq)) {
> + struct sk_buff *skb;
> + if (rq =3D=3D 1) { /* LL RQ1 */
> + void *pref;
> +
> + x =3D (wqe_index + 1) % skb_arr_rq1_len;
> + pref =3D (void*)skb_arr_rq1[x];
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + x =3D (wqe_index + 1) % skb_arr_rq1_len;
> + pref =3D (void*)(skb_arr_rq1[x]->data);
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + skb =3D skb_arr_rq1[wqe_index];
> + if (unlikely(!skb)) {
> + EDEB_ERR(4, "LL SBK=3DNULL, wqe_index=3D%d",
> + wqe_index);
> + skb =3D dev_alloc_skb(EHEA_LL_PKT_SIZE);
> + if (!skb)
> + panic("Alloc SKB failed");
> + }
> + skb_arr_rq1[wqe_index] =3D NULL;
> + ehea_fill_skb_ll(dev, skb, cqe);
> + } else if (rq =3D=3D 2) { /* RQ2 */
> + void *pref;
> + int skb_index =3D EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id);
> + x =3D (skb_index + 1) % port_res->skb_arr_rq2_len;
> + pref =3D (void*)skb_arr_rq2[x];
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + x =3D (skb_index + 1) % port_res->skb_arr_rq2_len;
> + pref =3D (void*)(skb_arr_rq2[x]->data);
> +
> + prefetch(pref);
> + prefetch(pref + EHEA_CACHE_LINE);
> + prefetch(pref + EHEA_CACHE_LINE * 2);
> + prefetch(pref + EHEA_CACHE_LINE * 3);
> + skb =3D skb_arr_rq2[skb_index];
> +
> + if (unlikely(!skb)) {
> + EDEB_ERR(4, "rq2: SKB=3DNULL, index=3D%d",
> + skb_index);
> + break;
> + }
> + skb_arr_rq2[skb_index] =3D NULL;
> + ehea_fill_skb(dev, skb, cqe);
> + processed_RQ2++;
> + } else {
> + void *pref;
> + int skb_index =3D EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id);
> + x =3D (skb_index + 1) % port_res->skb_arr_rq3_len;
> + pref =3D (void*)skb_arr_rq3[x];
> + prefetchw(pref);
> + prefetchw(pref + EHEA_CACHE_LINE);
> +
> + x =3D (skb_index + 1) % port_res->skb_arr_rq3_len;
> + pref =3D (void*)(skb_arr_rq3[x]->data);
> + prefetch(pref);
> + prefetch(pref + EHEA_CACHE_LINE);
> + prefetch(pref + EHEA_CACHE_LINE * 2);
> + prefetch(pref + EHEA_CACHE_LINE * 3);
> +
> + skb =3D skb_arr_rq3[skb_index];
> + if (unlikely(!skb)) {
> + EDEB_ERR(4, "rq3: SKB=3DNULL, index=3D%d",
> + skb_index);
> + break;
> + }
> + skb_arr_rq3[skb_index] =3D NULL;
> + ehea_fill_skb(dev, skb, cqe);
> + processed_RQ3++;
> + }
> +
> + EDEB(6, "About to pass SKB: dev=3D%p\n"
> + "skb=3D%p skb->data=3D%p skb->len=3D%d"
> + " skb->data_len=3D0x%x nr_frags=3D%d",
> + dev,
> + skb,
> + skb->data,
> + skb->len,
> + skb->data_len, skb_shinfo(skb)->nr_frags);
> + if (cqe->status & EHEA_CQE_VLAN_TAG_XTRACT) {
> + EDEB(7, "VLAN TAG extracted: %4x, vgrp=3D%p",
> + cqe->vlan_tag, port->vgrp);
> + EDEB(7, "vlan_devices[vlan_tag]=3D%p",
> + port->vgrp->vlan_devices[cqe->vlan_tag]);
> + vlan_hwaccel_receive_skb(skb, port->vgrp,
> + cqe->vlan_tag);
> + } else {
> + EDEB(7, "netif_receive_skb");
> + netif_receive_skb(skb);
> + }
> + EDEB(7, "SKB passed (netif_receive(skb) called)");
> +
> + } else {
> + struct sk_buff *skb;
> +
> + EDEB_ERR(4, "cqe->status indicating error: CQE:");
> + EDEB_DMP(4, (u8*)cqe, 4 * 16, "");
> + if (rq =3D=3D 2) {
> + processed_RQ2++;
> + skb =3D skb_arr_rq2[
> + EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)];
> + skb_arr_rq2[EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)] =3D NULL;
> + dev_kfree_skb(skb);
> + }
> + if (rq =3D=3D 3) {
> + processed_RQ3++;
> + skb =3D skb_arr_rq3[
> + EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)];
> + skb_arr_rq3[EHEA_BMASK_GET(EHEA_WR_ID_INDEX,
> + cqe->wr_id)] =3D NULL;
> + dev_kfree_skb(skb);
> + }
> + }
> + cqe =3D ehea_poll_rq1(qp, &wqe_index);
> + }
> +
> + dev->quota -=3D processed;
> + *budget -=3D processed;
> +
> + port_res->p_state.ehea_poll +=3D 1;
> +
> + port_res->rx_packets +=3D processed;
> +
> + ehea_refill_rq1(port_res, last_wqe_index, processed_RQ1);
> + ehea_refill_rq2(port_res, processed_RQ2);
> + ehea_refill_rq3(port_res, processed_RQ3);
> +
> + intreq =3D ((port_res->p_state.ehea_poll & 0xF) =3D=3D 0xF);
> +
> + EDEB_EX(7, "processed=3D%d, *budget=3D%d, dev->quota=3D%d",
> + processed, *budget, dev->quota);
> +
> + if (!cqe || intreq) {
> + netif_rx_complete(dev);
> + ehea_reset_cq_ep(port_res->recv_cq);
> + ehea_reset_cq_n1(port_res->recv_cq);
> + cqe =3D ipz_qeit_get_valid(&qp->ipz_rqueue1);
> + EDEB(7, "CQE=3D%p, break ehea_poll while loop", cqe);
> + if (!cqe || intreq)
> + return 0;
> + if (!netif_rx_reschedule(dev, my_quota))
> + return 0;
> + }
> + return 1;
> +}
The poll function seems too long and therefore hard to review. Please consi=
der=20
splitting it.=20
=2D-=20
Mit freundlichen Gr=FC=DFen / Best Regards
Christian Borntraeger
Linux Software Engineer zSeries Linux & Virtualization
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Segher Boessenkool @ 2006-08-09 9:52 UTC (permalink / raw)
To: michael; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <1155090210.7087.4.camel@localhost.localdomain>
> I was just re-reading this thread and this got me thinking. I think
> the
> current code does violate this rule if firmware has allocated more
> than
> one MSI to the device.
>
> In rtas_enable_msi() we ask firmware how many MSIs the device has been
> given (by firmware), we then return one to the driver, but leave any
> extras configured.
>
> So this might lead to the state where the card has been configured to
> use x MSIs, but we only tell the driver about 1 of them. I don't know
> enough PCI to grok if that's going to be a problem.
A device could in principle happily start using all MSIs it has been
assigned as soon as its global interrupt enable bit is set. So lying
to the driver about what MSIs are enabled can in principle cause nasty
problems.
In reality however, on any (recent) device, every interrupt cause also
has its own enable bits that the driver needs to set. So we're sort-of
safe here.
Eventually, we should change the API for pci_enable_msi() so that it
can enable multiple MSIs as well; an arch implementation can always
choose to do just one. This lets us roll the APIs for MSI and MSI-X
into one as well btw -- always a good thing!
Segher
^ permalink raw reply
* Re: [PATCH 5/6] ehea: makefile
From: Sam Ravnborg @ 2006-08-09 9:50 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linux-ppc, Christoph Raisch,
Marcus Eder
In-Reply-To: <44D99F74.1000704@de.ibm.com>
On Wed, Aug 09, 2006 at 10:40:20AM +0200, Jan-Bernd Themann wrote:
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
>
>
> drivers/net/ehea/Makefile | 7 +++++++
> 1 file changed, 7 insertions(+)
>
>
>
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/Makefile 1969-12-31
> 16:00:00.000000000 -0800
> +++ kernel/drivers/net/ehea/Makefile 2006-08-08 23:59:38.083467216 -0700
> @@ -0,0 +1,7 @@
> +#
> +# Makefile for the eHEA ethernet device driver for IBM eServer System p
> +#
> +
> +ehea_mod-objs = ehea_main.o ehea_phyp.o ehea_qmr.o ehea_ethtool.o
> ehea_phyp.o
> +obj-$(CONFIG_EHEA) += ehea_mod.o
> +
Using -objs is deprecated, please use ehea_mod-y.
This needs to be documented and later warned upon which I will do soon.
Sam
^ permalink raw reply
* Re: [PATCH][0/2] RTAS MSI
From: Michael Ellerman @ 2006-08-09 10:27 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: Paul Mackerras, linuxppc-dev
In-Reply-To: <F5E5EF18-6452-4E9D-8A43-6D1CE9C3E43E@kernel.crashing.org>
[-- Attachment #1: Type: text/plain, Size: 2225 bytes --]
On Wed, 2006-08-09 at 11:52 +0200, Segher Boessenkool wrote:
> > I was just re-reading this thread and this got me thinking. I think
> > the
> > current code does violate this rule if firmware has allocated more
> > than
> > one MSI to the device.
> >
> > In rtas_enable_msi() we ask firmware how many MSIs the device has been
> > given (by firmware), we then return one to the driver, but leave any
> > extras configured.
> >
> > So this might lead to the state where the card has been configured to
> > use x MSIs, but we only tell the driver about 1 of them. I don't know
> > enough PCI to grok if that's going to be a problem.
>
> A device could in principle happily start using all MSIs it has been
> assigned as soon as its global interrupt enable bit is set. So lying
> to the driver about what MSIs are enabled can in principle cause nasty
> problems.
>
> In reality however, on any (recent) device, every interrupt cause also
> has its own enable bits that the driver needs to set. So we're sort-of
> safe here.
Yeah ok, I thought that was probably the answer - it's possible, but
probably not a problem IRL.
> Eventually, we should change the API for pci_enable_msi() so that it
> can enable multiple MSIs as well; an arch implementation can always
> choose to do just one. This lets us roll the APIs for MSI and MSI-X
> into one as well btw -- always a good thing!
Yeah. Looking at the way drivers use the current API (and there's only a
few), they generally seem to try to enable n MSI-X vectors, then
fallback to a single MSI then LSI. And then there's some that just want
a single MSI as a drop-in replacement for LSI.
So I think we could have pci_enable_msi(dev), which would enable a
single MSI _or_ MSI-X vector, depending on what's available. That'd be
used by drivers that just want a simple replacement for LSI. And then
pci_enable_multi_msi(dev, num_irqs) which would give the driver num_irqs
MSI or MSI-X vectors.
cheers
--
Michael Ellerman
IBM OzLabs
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: 191 bytes --]
^ permalink raw reply
* Re: [RFC] Debugging with a HW probe.
From: Jimi Xenidis @ 2006-08-09 10:44 UTC (permalink / raw)
To: Milton Miller; +Cc: linuxppc-dev
In-Reply-To: <311550865236b8b45674.846930886.miltonm@bga.com>
On Aug 8, 2006, at 9:22 PM, Milton Miller wrote:
> On Sun Aug 6 2006 09:42:16 AM CDT, Jimi Xenidis wrote:
>> On the XenPPC project we've been playing around with using GDB to
>> source debug Linux (and Xen) using a RiscWatch HW probe.
>
>> We have found it useful to teach xmon to make this call so we can
>> then
>> debug the SW thru the probe. Is this useful to anyone else
>
> Since you only invoke the attention on command from the debugger, how
> is this better than just invoking the stop command from the probe?
> Is it you
> are not dispatched out? That you are not at a random point in the
> input
> polling?
Thats exactly it!
If I get the probe to stop the CPU I could stop in the OS or in a
user app. Since we are working on Xen it could be Xen or any number
of OSes or user apps on OSes.
When interrogating the machine state, the probe (almost) respects the
modes of the CPU and MMU so memory accesses are translated (if xlate
is on). Since, probe "soft breakpoints" are ATTN instructions as
well they get written into memory by the probe.
Having SW "call out" allows me to make sure that I'm in the address
space I care about.
Since I only invoke it from xmon it assumes you have xmon support and
to really be useful you need to SysReq to xmon.
I could be useful to make this part of SysReq, but I think we want to
make sure that its use is entirely intentional.
You can also insert 'asm volatile(".long 0x200;nop");' in you own
code or even add it to BUG()/panic() and skip the suffering the xmon/
SysReq trap.
BTW: I say "almost" because the probe does not respect the truncating
of the upper bits when xlate is off and 0xC00... addresses are
useless, we hacked the gdb stub to work around that.
BTW2: (I'm sure obvious to some), Since the probe writes ATTN
instructions, I do not know what would happen if the probe wrote ATTN
to an unmapped page, this is why debugging user space might be useless.
-JX
^ permalink raw reply
* RE: Trouble on building crossover compiler for Synology 8041 PPCbased NAS
From: Li Yang-r58472 @ 2006-08-09 11:30 UTC (permalink / raw)
To: David Hawkins, chun fung siu; +Cc: linuxppc-embedded
In-Reply-To: <44D8C02D.1070205@ovro.caltech.edu>
http://images.tomshardware.com/2006/06/28/not_going_wrong_with_the_synol
ogy_ds/synology_ds106e_main_board_big.jpg
Here is a picture of the exact model. I can confirm that it's a
MPC8241.
Best Regards,
Leo
> -----Original Message-----
> From: linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org
> [mailto:linuxppc-embedded-bounces+leoli=3Dfreescale.com@ozlabs.org] On
Behalf Of
> David Hawkins
> Sent: Wednesday, August 09, 2006 12:48 AM
> To: chun fung siu
> Cc: linuxppc-embedded@ozlabs.org
> Subject: Re: Trouble on building crossover compiler for Synology 8041
PPCbased NAS
>=20
> chun fung siu wrote:
> > Hi,
> >
> > I recently bought a Synology Network Attached Server DS-106e, run
using
> > a "Linux 2. 4.22-uc-0" Kernel, under 8041 PPC, no "gcc" installed. I
> > want to build a crosslink gcc compiler for it in another "debian 2.6
> > kernel" linux. I find many options in the crosslink build script on
ppc,
> > but can't find any option for 8041 PPC. So what option should I
choose?
> > And further can I put the artifacts just compiled in my Network
Attached
> > Server? So that I can compile anything directly in my NAS.
>=20
> The processor is probably an *MPC8241*.
>=20
> The DS101g is also an MPC8241. So this should provide you with
> some useful info:
>=20
> http://www.nslu2-linux.org/wiki/DS101/HomePage
> http://www.nslu2-linux.org/wiki/DS101/DS101GHardware
>=20
> Dave
>=20
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: boot problems on pseries
From: Olaf Hering @ 2006-08-09 11:51 UTC (permalink / raw)
To: Mark Fasheh; +Cc: linuxppc-dev
In-Reply-To: <20060809013609.GA10876@ca-server1.us.oracle.com>
On Tue, Aug 08, 2006 at 06:36:09PM -0700, Mark Fasheh wrote:
> Recently, I discovered that newer kernels would no longer fully boot.
The IDE controller got irq32 in older kernels, now it gets irq17.
...
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
AMD8111: IDE controller at PCI slot 0000:00:04.1
AMD8111: chipset revision 3
AMD8111: 0000:00:04.1 (rev 03) UDMA133 controller
AMD8111: 100% native mode on irq 17
ide0: BM-DMA at 0x7c00-0x7c07, BIOS settings: hda:pio, hdb:pio
ide1: BM-DMA at 0x7c08-0x7c0f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: TOSHIBA MK6026GAXB, ATA DISK drive
ide0 at 0x7400-0x7407,0x6c02 on irq 17
Probing IDE interface ide1...
Probing IDE interface ide1...
hda: max request size: 128KiB
hda: lost interrupt
hda: lost interrupt
...
^ permalink raw reply
* Re: PowerPC Local Bus
From: Fredrik Roubert @ 2006-08-09 12:29 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-embedded
In-Reply-To: <5C1C19D6-8FC8-46AF-9C4B-B9989B1A997B@kernel.crashing.org>
On Tue 08 Aug 17:03 CEST 2006, Kumar Gala wrote:
> The reason you haven't seen any code is due to several reasons. One,
> FPGA/localbus implementations can be very specific and thus reuse is
> difficult. Two, some of this code tends to end up it boot loaders to
> setup the UPM (take a look at U-boot for possible UPM config code).
OK, so you do all the setup in the boot loader and then the driver just
needs to ioremap() the FPGA? That sounds reasonable and explains why I
haven't found any kernel source code relating to this ...
I just didn't expect the kernel to rely on the boot loader to configure
this. Is that the recommended way to to it?
Cheers // Fredrik Roubert
--
Visserij 192 | +32 473 344527 / +46 708 776974
BE-9000 Gent | http://www.df.lth.se/~roubert/
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Johannes Berg @ 2006-08-09 12:29 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <s5h7j1idrvf.wl%tiwai@suse.de>
Takashi Iwai wrote:
>> Yeah, I really should know :) But I'm not sure at the moment, and the
>> powermac I own is a few hundred kilometers away...
>>
>
> Don't worry, we can wait :)
>
Maybe someone on linuxppc-dev can quickly check? Does a G5 use
I2C_POWERMAC for access to the codecs? I think it does, but there are
other I2C busses as well.
>> That looks good to me, and should get rid of the build failure. However,
>> if one doesn't configure I2C_POWERMAC, no codec will ever be found at
>> runtime.
>>
>
> Yes, that's my concern, too.
>
I'm not sure how much we should force the users to a sensible
configuration ;) But I suppose selecting I2C_POWERMAC is fine for all
relevant machines for now.
johannes
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Takashi Iwai @ 2006-08-09 12:31 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <44D9D532.9010200@sipsolutions.net>
At Wed, 09 Aug 2006 14:29:38 +0200,
Johannes Berg wrote:
>
> Takashi Iwai wrote:
> >> Yeah, I really should know :) But I'm not sure at the moment, and the
> >> powermac I own is a few hundred kilometers away...
> >>
> >
> > Don't worry, we can wait :)
> >
> Maybe someone on linuxppc-dev can quickly check? Does a G5 use
> I2C_POWERMAC for access to the codecs? I think it does, but there are
> other I2C busses as well.
> >> That looks good to me, and should get rid of the build failure. However,
> >> if one doesn't configure I2C_POWERMAC, no codec will ever be found at
> >> runtime.
> >>
> >
> > Yes, that's my concern, too.
> >
> I'm not sure how much we should force the users to a sensible
> configuration ;) But I suppose selecting I2C_POWERMAC is fine for all
> relevant machines for now.
Agreed.
A relevant question: do we need I2C_POWERMAC for both onyx and tas?
Takashi
^ permalink raw reply
* Re: [PATCH] Fix loop logic in irq_alloc_virt()
From: Benjamin Herrenschmidt @ 2006-08-09 9:38 UTC (permalink / raw)
To: Michael Ellerman; +Cc: linuxppc-dev list
In-Reply-To: <20060802004852.C66FB67B7F@ozlabs.org>
On Wed, 2006-08-02 at 10:48 +1000, Michael Ellerman wrote:
> There's a bug in irq_alloc_virt() if it's asked for more than 1 interrupt,
> if it can't find a slot it might look past the end of the irq_map.
>
> I think this is a fix. No one in the kernel actually calls this with
> count > 1, so it's not critical.
Good catch. /me stupid.
> Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> ---
>
> arch/powerpc/kernel/irq.c | 19 ++++++++++---------
> 1 file changed, 10 insertions(+), 9 deletions(-)
>
> Index: to-merge/arch/powerpc/kernel/irq.c
> ===================================================================
> --- to-merge.orig/arch/powerpc/kernel/irq.c
> +++ to-merge/arch/powerpc/kernel/irq.c
> @@ -728,7 +728,6 @@ unsigned int irq_alloc_virt(struct irq_h
> {
> unsigned long flags;
> unsigned int i, j, found = NO_IRQ;
> - unsigned int limit = irq_virq_count - count;
>
> if (count == 0 || count > (irq_virq_count - NUM_ISA_INTERRUPTS))
> return NO_IRQ;
> @@ -745,14 +744,16 @@ unsigned int irq_alloc_virt(struct irq_h
> /* Look for count consecutive numbers in the allocatable
> * (non-legacy) space
> */
> - for (i = NUM_ISA_INTERRUPTS; i <= limit; ) {
> - for (j = i; j < (i + count); j++)
> - if (irq_map[j].host != NULL) {
> - i = j + 1;
> - continue;
> - }
> - found = i;
> - break;
> + for (i = NUM_ISA_INTERRUPTS, j = 0; i < irq_virq_count; i++) {
> + if (irq_map[i].host != NULL)
> + j = 0;
> + else
> + j++;
> +
> + if (j == count) {
> + found = i - count + 1;
> + break;
> + }
> }
> if (found == NO_IRQ) {
> spin_unlock_irqrestore(&irq_big_lock, flags);
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Benjamin Herrenschmidt @ 2006-08-09 11:18 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1154464346.19994.4.camel@cashmere.sps.mot.com>
On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> Folks,
>
> Where should we place the sources for the OF Flat Device
> Tree source files? They used to be in U-Boot, but that
> isn't happening any more.
Why ? While having device-tree's in zImages is good to handle firmwares
that can't pass them, I still think that the proper thing to do is to
have the firmware provide the DT to the kernel. Did Denk decide once for
all against having DTs passed by uboot at all ? In which case, it's
probably time to consider a fork...
> One semi-obvious place would be to co-locate them with
> their corresponding Linux arch/powerpc/platform directory.
> Another would be to have a new directory full of them
> under, say, arch/powerpc/devtrees or so.
>
> Are there other suggestions or better ideas?
>
> Thanks,
> jdl
>
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Benjamin Herrenschmidt @ 2006-08-09 11:22 UTC (permalink / raw)
To: Christoph Hellwig; +Cc: linuxppc-dev, Michael Neuling, paulus, anton, sfr
In-Reply-To: <20060805124544.GB23494@lst.de>
On Sat, 2006-08-05 at 14:45 +0200, Christoph Hellwig wrote:
> On Fri, Aug 04, 2006 at 03:53:19PM +1000, Michael Neuling wrote:
> > This adds a shadow buffer for the SLBs and regsiters it with PHYP.
> > Only the bolted SLB entries (first 3) are saved.
>
> What is a SLB shadow buffer and why do we need it? (I don't want to
> question the patch but rather learn a little more about lowlevel ppc64
> mmu details)
Yeah, same question :) I don't have my PAPR at hand and I'm still
travellling but I'm curious about that one...
I would suspect it allows the HV to save/restore SLBs when sharing a
processor between partitions but then... the kernel requires that anyway
so either the current code is bogus and that's pretty bad (which I don't
think so) or maybe the fact that we didn't register the shadow caused HV
to always save/restore the entire SLB, while by using the shadow, we let
it save/restore only the bolted entries we put in there (and just
re-fault the other ones). If it's not that, then what ? :)
Ben.
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Johannes Berg @ 2006-08-09 12:38 UTC (permalink / raw)
To: Takashi Iwai; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <s5h4pwmdr9o.wl%tiwai@suse.de>
Takashi Iwai wrote:
> A relevant question: do we need I2C_POWERMAC for both onyx and tas?
>
Yes, there are PowerBooks and G5s with either. Actually, a bit more
thinking about this I'm pretty sure that it is used on all G5s by way of
how things are hooked up. There are SMU I2C busses too but they surely
don't connect any sound i2c stuff.
johannes
^ permalink raw reply
* Re: [PATCH][2/2] RTAS MSI
From: Benjamin Herrenschmidt @ 2006-08-09 9:50 UTC (permalink / raw)
To: michael; +Cc: linuxppc-dev, PaulMackerras
In-Reply-To: <1154509462.26242.9.camel@localhost.localdomain>
> I'm only just starting to get benh's new irq code, but I think
> irq_find_host(dn) isn't doing what we want here. It's probably harmless,
> but AFAICT irq_find_host() is only meant to be called when you have the
> node of the irq controller, not for an arbitrary dn. The doco's a bit
> ambiguous:
>
> * irq_find_host - Locates a host for a given device node
> * @node: device-tree node of the interrupt controller
>
> But looking at the implementation, it doesn't do a search up the tree or
> anything, it just checks node against each host.
For pSeries, passing NULL is fine for host anyway as there is only one
domain that is relevant for MSIs (there might be a 8259 legacy domain
too but it's not relevant) and that domain is set to be the default
host.
> Also, since's benh's latest patch went in we'll have to split this into
> two calls, I think we want:
>
> virq = irq_create_mapping(NULL ???, ret[0]);
> set_irq_type(virq, ret[1] ? IRQ_TYPE_EDGE_RISING : IRQ_TYPE_LEVEL_LOW);
MSIs are always edge (though there might be an issue with some P5IOC
errata lurking here...). The xics code doesn't care much at this point
though.
Ben.
^ permalink raw reply
* Re: [Alsa-devel] Linux v2.6.18-rc4, snd-aoa link error
From: Takashi Iwai @ 2006-08-09 12:52 UTC (permalink / raw)
To: Johannes Berg; +Cc: linuxppc-dev, Lee Revell, alsa-devel
In-Reply-To: <44D9D74E.6010009@sipsolutions.net>
At Wed, 09 Aug 2006 14:38:38 +0200,
Johannes Berg wrote:
>
> Takashi Iwai wrote:
> > A relevant question: do we need I2C_POWERMAC for both onyx and tas?
> >
> Yes, there are PowerBooks and G5s with either. Actually, a bit more
> thinking about this I'm pretty sure that it is used on all G5s by way of
> how things are hooked up. There are SMU I2C busses too but they surely
> don't connect any sound i2c stuff.
OK, now I added both I2C and I2C_POWERMAC and committed to ALSA tree.
Takashi
diff -r 67e0e0ca5f65 -r f72c2a462f76 aoa/codecs/Kconfig
--- a/aoa/codecs/Kconfig Wed Aug 09 14:33:27 2006 +0200
+++ b/aoa/codecs/Kconfig Wed Aug 09 14:51:14 2006 +0200
@@ -1,6 +1,8 @@ config SND_AOA_ONYX
config SND_AOA_ONYX
tristate "support Onyx chip"
depends on SND_AOA
+ select I2C
+ select I2C_POWERMAC
---help---
This option enables support for the Onyx (pcm3052)
codec chip found in the latest Apple machines
@@ -18,6 +20,8 @@ config SND_AOA_TAS
config SND_AOA_TAS
tristate "support TAS chips"
depends on SND_AOA
+ select I2C
+ select I2C_POWERMAC
---help---
This option enables support for the tas chips
found in a lot of Apple Machines, especially
^ permalink raw reply
* Re: RFC: Location for Device Tree Sources?
From: Josh Boyer @ 2006-08-09 12:56 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <1155122309.4040.94.camel@localhost.localdomain>
On Wed, 2006-08-09 at 13:18 +0200, Benjamin Herrenschmidt wrote:
> On Tue, 2006-08-01 at 15:32 -0500, Jon Loeliger wrote:
> > Folks,
> >
> > Where should we place the sources for the OF Flat Device
> > Tree source files? They used to be in U-Boot, but that
> > isn't happening any more.
>
> Why ? While having device-tree's in zImages is good to handle firmwares
> that can't pass them, I still think that the proper thing to do is to
> have the firmware provide the DT to the kernel. Did Denk decide once for
> all against having DTs passed by uboot at all ? In which case, it's
> probably time to consider a fork...
We're only talking about the _source_ files. The .dts files. Not the
binary trees themselves.
The basic summary is that having a .dts in the kernel for every
defconfig would be good. (I think that was the summary anyway.)
josh
^ permalink raw reply
* Re: [PATCH] SLB shadow buffer
From: Segher Boessenkool @ 2006-08-09 13:01 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: sfr, Michael Neuling, linuxppc-dev, paulus, anton
In-Reply-To: <1155122580.4040.96.camel@localhost.localdomain>
>> What is a SLB shadow buffer and why do we need it? (I don't want to
>> question the patch but rather learn a little more about lowlevel
>> ppc64
>> mmu details)
>
> Yeah, same question :) I don't have my PAPR at hand and I'm still
> travellling but I'm curious about that one...
>
> I would suspect it allows the HV to save/restore SLBs when sharing a
> processor between partitions but then... the kernel requires that
> anyway
> so either the current code is bogus and that's pretty bad (which I
> don't
> think so) or maybe the fact that we didn't register the shadow
> caused HV
> to always save/restore the entire SLB, while by using the shadow,
> we let
> it save/restore only the bolted entries we put in there (and just
> re-fault the other ones). If it's not that, then what ? :)
Yep, that's it (and I do have a PAPR at hand ;-) )
Note that we could also store "volatile" entries in the shadow buffer;
that's supposed to improve performance.
Segher
^ permalink raw reply
* Re: PowerPC Local Bus
From: Kumar Gala @ 2006-08-09 13:05 UTC (permalink / raw)
To: Fredrik Roubert; +Cc: linuxppc-embedded
In-Reply-To: <20060809122904.GE3918@igloo.df.lth.se>
On Aug 9, 2006, at 7:29 AM, Fredrik Roubert wrote:
> On Tue 08 Aug 17:03 CEST 2006, Kumar Gala wrote:
>
>> The reason you haven't seen any code is due to several reasons. One,
>> FPGA/localbus implementations can be very specific and thus reuse is
>> difficult. Two, some of this code tends to end up it boot loaders to
>> setup the UPM (take a look at U-boot for possible UPM config code).
>
> OK, so you do all the setup in the boot loader and then the driver
> just
> needs to ioremap() the FPGA? That sounds reasonable and explains why I
> haven't found any kernel source code relating to this ...
>
> I just didn't expect the kernel to rely on the boot loader to
> configure
> this. Is that the recommended way to to it?
I don't think there is any recommendation one way or the other. Its
just that the boards that are currently supported in the kernel doing
have FGPAs needing UPM config and thus there isn't any code one way
or the other.
- kumar
^ permalink raw reply
* Re: [PATCH 1/6] ehea: interface to network stack
From: Alexey Dobriyan @ 2006-08-09 13:06 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, netdev, linux-kernel, linuxppc-dev,
Christoph Raisch, Marcus Eder
In-Reply-To: <44D99EFC.3000105@de.ibm.com>
On Wed, Aug 09, 2006 at 10:38:20AM +0200, Jan-Bernd Themann wrote:
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_main.c
> +++ kernel/drivers/net/ehea/ehea_main.c
> +static inline u64 get_swqe_addr(u64 tmp_addr, int addr_seg)
> +{
> + u64 addr;
> + addr = tmp_addr;
> + return addr;
> +}
> +
> +static inline u64 get_rwqe_addr(u64 tmp_addr)
> +{
> + return tmp_addr;
> +}
The point of this exercise?
> +static inline int ehea_refill_rq3_def(struct ehea_port_res *pr, int nr_of_wqes)
Way too big to be inline function.
> +{
> + int i;
> + int ret = 0;
> + struct ehea_qp *qp;
> + struct ehea_rwqe *rwqe;
> + int skb_arr_rq3_len = pr->skb_arr_rq3_len;
> + struct sk_buff **skb_arr_rq3 = pr->skb_arr_rq3;
> + EDEB_EN(8, "pr=%p, nr_of_wqes=%d", pr, nr_of_wqes);
> + if (nr_of_wqes == 0)
> + return -EINVAL;
> + qp = pr->qp;
> + for (i = 0; i < nr_of_wqes; i++) {
> + int index = pr->skb_rq3_index++;
> + struct sk_buff *skb = dev_alloc_skb(EHEA_MAX_PACKET_SIZE
> + + NET_IP_ALIGN);
> +
> + if (!skb) {
> + EDEB_ERR(4, "No memory for skb. Only %d rwqe
> filled.",
> + i);
> + ret = -ENOMEM;
> + break;
> + }
> + skb_reserve(skb, NET_IP_ALIGN);
> +
> + rwqe = ehea_get_next_rwqe(qp, 3);
> + pr->skb_rq3_index %= skb_arr_rq3_len;
> + skb_arr_rq3[index] = skb;
> + rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE,
> EHEA_RWQE3_TYPE)
> + | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
> + rwqe->sg_list[0].l_key = ehea_get_recv_lkey(pr);
> + rwqe->sg_list[0].vaddr = get_rwqe_addr((u64)skb->data);
> + rwqe->sg_list[0].len = EHEA_MAX_PACKET_SIZE;
> + rwqe->data_segments = 1;
> + }
> +
> + /* Ring doorbell */
> + iosync();
> + ehea_update_rq3a(qp, i);
> + EDEB_EX(8, "");
> + return ret;
> +}
> +
> +
> +static inline int ehea_refill_rq3(struct ehea_port_res *pr, int nr_of_wqes)
> +{
> + return ehea_refill_rq3_def(pr, nr_of_wqes);
> +}
ehea_refill_rq3[123] appears to be 1:1 wrappers around
ehea_refill_rq3[123]_def. Any idea behind them?
> + init_attr = (struct ehea_qp_init_attr*)
> + kzalloc(sizeof(struct ehea_qp_init_attr), GFP_KERNEL);
Useless cast.
> + pr->skb_arr_sq = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
Useless cast
> + pr->skb_arr_rq1 = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
> + pr->skb_arr_rq2 = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
> + pr->skb_arr_rq3 = (struct sk_buff**)vmalloc(sizeof(struct sk_buff*)
> + * (max_rq_entries + 1));
> +static int ehea_ioctl(struct net_device *dev, struct ifreq *ifr, int cmd)
> +{
> + EDEB_ERR(4, "ioctl not supported: dev=%s cmd=%d", dev->name, cmd);
Then copy NULL into ->do_ioctl!
> + return -EOPNOTSUPP;
> +}
> + ehea_port_cb_0 = kzalloc(H_CB_ALIGNMENT, GFP_KERNEL);
> +
> + if (!ehea_port_cb_0) {
> + EDEB_ERR(4, "No memory for ehea_port control block");
> + ret = -ENOMEM;
> + goto kzalloc_failed;
> + }
> +
> + memcpy((u8*)(&(ehea_port_cb_0->port_mac_addr)),
> + (u8*)&(mac_addr->sa_data[0]), 6);
No casts on memcpy arguments.
> + memcpy((u8*)&ehea_mcl_entry->macaddr, mc_mac_addr, ETH_ALEN);
> +static inline void ehea_xmit2(struct sk_buff *skb,
> + struct net_device *dev, struct ehea_swqe *swqe,
> + u32 lkey)
> +{
> + int nfrags;
> + unsigned short skb_protocol = skb->protocol;
Useless variable. And it should be __be16, FYI.
> + nfrags = skb_shinfo(skb)->nr_frags;
> + EDEB_EN(7, "skb->nfrags=%d (0x%X)", nfrags, nfrags);
> +
> + if (skb_protocol == ETH_P_IP) {
ITYM, htons(ETH_P_IP).
> +static inline void ehea_xmit3(struct sk_buff *skb,
> + struct net_device *dev, struct ehea_swqe *swqe)
> +{
> + int i;
> + skb_frag_t *frag;
> + int nfrags = skb_shinfo(skb)->nr_frags;
> + u8 *imm_data = &swqe->u.immdata_nodesc.immediate_data[0];
> + u64 skb_protocol = skb->protocol;
Useless var.
> +
> + EDEB_EN(7, "");
> + if (likely(skb_protocol == ETH_P_IP)) {
htons(ETH_P_IP)
^ permalink raw reply
* Re: [PATCH 2/6] ehea: pHYP interface
From: Arnd Bergmann @ 2006-08-09 13:14 UTC (permalink / raw)
To: linuxppc-dev
Cc: Thomas Klein, netdev, linux-kernel, Christoph Raisch, Marcus Eder
In-Reply-To: <44D99F1A.4080905@de.ibm.com>
On Wednesday 09 August 2006 10:38, Jan-Bernd Themann wrote:
> --- linux-2.6.18-rc4-orig/drivers/net/ehea/ehea_hcall.h=A01969-12-31 16:0=
0:00.000000000 -0800
> +++ kernel/drivers/net/ehea/ehea_hcall.h=A0=A0=A0=A0=A0=A0=A0=A02006-08-0=
8 23:59:38.111462960 -0700
> @@ -0,0 +1,52 @@
> +
> +/**
> + * This file contains HCALL defines that are to be included in the appro=
priate
> + * kernel files later
> + */
> +
> +#define H_ALLOC_HEA_RESOURCE =A0 0x278
> +#define H_MODIFY_HEA_QP =A0 =A0 =A0 =A00x250
> +#define H_QUERY_HEA_QP =A0 =A0 =A0 =A0 0x254
> +#define H_QUERY_HEA =A0 =A0 =A0 =A0 =A0 =A00x258
> +#define H_QUERY_HEA_PORT =A0 =A0 =A0 0x25C
> +#define H_MODIFY_HEA_PORT =A0 =A0 =A00x260
> +#define H_REG_BCMC =A0 =A0 =A0 =A0 =A0 =A0 0x264
> +#define H_DEREG_BCMC =A0 =A0 =A0 =A0 =A0 0x268
> +#define H_REGISTER_HEA_RPAGES =A00x26C
> +#define H_DISABLE_AND_GET_HEA =A00x270
> +#define H_GET_HEA_INFO =A0 =A0 =A0 =A0 0x274
> +#define H_ADD_CONN =A0 =A0 =A0 =A0 =A0 =A0 0x284
> +#define H_DEL_CONN =A0 =A0 =A0 =A0 =A0 =A0 0x288
I guess these should go to include/asm-powerpc/hvcall.h instead.
Arnd <><
^ permalink raw reply
* .tc entries question
From: Jonathan Bartlett @ 2006-08-09 13:15 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <20060725140634.GH6872@bubble.grove.modra.org>
Another 64-bit Elf question, this one about the TOC. In many examples,
for defining toc entries, there is some syntax like this:
name_to_refer_to_this:
.tc seemingly_unused_name[TC], data_here
I haven't figured out what the purpose of the name immediately preceding
[TC] is. In fact, it seems that in most cases it can simply be left out.
Is this just a holdover from a previous binary format, or does
"seemingly_unused_name" actually get used in some fashion?
Thanks,
Jon
^ 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