* [PATCH/RESENT] ehea: Whitespace cleanup
From: Jan-Bernd Themann @ 2007-07-02 11:00 UTC (permalink / raw)
To: Jeff Garzik
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
This patch fixes several whitespace issues.
Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
---
diff --git a/drivers/net/ehea/ehea.h b/drivers/net/ehea/ehea.h
index c0f81b5..abaf3ac 100644
--- a/drivers/net/ehea/ehea.h
+++ b/drivers/net/ehea/ehea.h
@@ -39,7 +39,7 @@
#include <asm/io.h>
#define DRV_NAME "ehea"
-#define DRV_VERSION "EHEA_0064"
+#define DRV_VERSION "EHEA_0065"
#define EHEA_MSG_DEFAULT (NETIF_MSG_LINK | NETIF_MSG_TIMER \
| NETIF_MSG_RX_ERR | NETIF_MSG_TX_ERR)
@@ -136,10 +136,10 @@ void ehea_dump(void *adr, int len, char *msg);
(0xffffffffffffffffULL >> ((64 - (mask)) & 0xffff))
#define EHEA_BMASK_SET(mask, value) \
- ((EHEA_BMASK_MASK(mask) & ((u64)(value))) << EHEA_BMASK_SHIFTPOS(mask))
+ ((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)))
+ (EHEA_BMASK_MASK(mask) & (((u64)(value)) >> EHEA_BMASK_SHIFTPOS(mask)))
/*
* Generic ehea page
@@ -190,7 +190,7 @@ struct ehea_av;
* Queue attributes passed to ehea_create_qp()
*/
struct ehea_qp_init_attr {
- /* input parameter */
+ /* input parameter */
u32 qp_token; /* queue token */
u8 low_lat_rq1;
u8 signalingtype; /* cqe generation flag */
@@ -212,7 +212,7 @@ struct ehea_qp_init_attr {
u64 recv_cq_handle;
u64 aff_eq_handle;
- /* output parameter */
+ /* output parameter */
u32 qp_nr;
u16 act_nr_send_wqes;
u16 act_nr_rwqes_rq1;
@@ -279,12 +279,12 @@ struct ehea_qp {
* Completion Queue attributes
*/
struct ehea_cq_attr {
- /* input parameter */
+ /* input parameter */
u32 max_nr_of_cqes;
u32 cq_token;
u64 eq_handle;
- /* output parameter */
+ /* output parameter */
u32 act_nr_of_cqes;
u32 nr_pages;
};
diff --git a/drivers/net/ehea/ehea_hw.h b/drivers/net/ehea/ehea_hw.h
index 1246757..1af7ca4 100644
--- a/drivers/net/ehea/ehea_hw.h
+++ b/drivers/net/ehea/ehea_hw.h
@@ -211,34 +211,34 @@ static inline void epa_store_acc(struct h_epa epa, u32 offset, u64 value)
}
#define epa_store_eq(epa, offset, value)\
- epa_store(epa, EQTEMM_OFFSET(offset), value)
+ epa_store(epa, EQTEMM_OFFSET(offset), value)
#define epa_load_eq(epa, offset)\
- epa_load(epa, EQTEMM_OFFSET(offset))
+ epa_load(epa, EQTEMM_OFFSET(offset))
#define epa_store_cq(epa, offset, value)\
- epa_store(epa, CQTEMM_OFFSET(offset), value)
+ epa_store(epa, CQTEMM_OFFSET(offset), value)
#define epa_load_cq(epa, offset)\
- epa_load(epa, CQTEMM_OFFSET(offset))
+ epa_load(epa, CQTEMM_OFFSET(offset))
#define epa_store_qp(epa, offset, value)\
- epa_store(epa, QPTEMM_OFFSET(offset), value)
+ epa_store(epa, QPTEMM_OFFSET(offset), value)
#define epa_load_qp(epa, offset)\
- epa_load(epa, QPTEMM_OFFSET(offset))
+ epa_load(epa, QPTEMM_OFFSET(offset))
#define epa_store_qped(epa, offset, value)\
- epa_store(epa, QPEDMM_OFFSET(offset), value)
+ epa_store(epa, QPEDMM_OFFSET(offset), value)
#define epa_load_qped(epa, offset)\
- epa_load(epa, QPEDMM_OFFSET(offset))
+ epa_load(epa, QPEDMM_OFFSET(offset))
#define epa_store_mrmw(epa, offset, value)\
- epa_store(epa, MRMWMM_OFFSET(offset), value)
+ epa_store(epa, MRMWMM_OFFSET(offset), value)
#define epa_load_mrmw(epa, offset)\
- epa_load(epa, MRMWMM_OFFSET(offset))
+ epa_load(epa, MRMWMM_OFFSET(offset))
#define epa_store_base(epa, offset, value)\
- epa_store(epa, HCAGR_OFFSET(offset), value)
+ epa_store(epa, HCAGR_OFFSET(offset), value)
#define epa_load_base(epa, offset)\
- epa_load(epa, HCAGR_OFFSET(offset))
+ epa_load(epa, HCAGR_OFFSET(offset))
static inline void ehea_update_sqa(struct ehea_qp *qp, u16 nr_wqes)
{
diff --git a/drivers/net/ehea/ehea_main.c b/drivers/net/ehea/ehea_main.c
index 9e13433..bdb5241 100644
--- a/drivers/net/ehea/ehea_main.c
+++ b/drivers/net/ehea/ehea_main.c
@@ -81,7 +81,7 @@ MODULE_PARM_DESC(use_mcs, " 0:NAPI, 1:Multiple receive queues, Default = 1 ");
static int port_name_cnt = 0;
static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
- const struct of_device_id *id);
+ const struct of_device_id *id);
static int __devexit ehea_remove(struct ibmebus_dev *dev);
@@ -236,7 +236,7 @@ static int ehea_refill_rq_def(struct ehea_port_res *pr,
rwqe = ehea_get_next_rwqe(qp, rq_nr);
rwqe->wr_id = EHEA_BMASK_SET(EHEA_WR_ID_TYPE, wqe_type)
- | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
+ | EHEA_BMASK_SET(EHEA_WR_ID_INDEX, index);
rwqe->sg_list[0].l_key = pr->recv_mr.lkey;
rwqe->sg_list[0].vaddr = (u64)skb->data;
rwqe->sg_list[0].len = packet_size;
@@ -427,7 +427,7 @@ static struct ehea_cqe *ehea_proc_rwqes(struct net_device *dev,
break;
}
skb_copy_to_linear_data(skb, ((char*)cqe) + 64,
- cqe->num_bytes_transfered - 4);
+ cqe->num_bytes_transfered - 4);
ehea_fill_skb(port->netdev, skb, cqe);
} else if (rq == 2) { /* RQ2 */
skb = get_skb_by_index(skb_arr_rq2,
@@ -618,7 +618,7 @@ static struct ehea_port *ehea_get_port(struct ehea_adapter *adapter,
for (i = 0; i < EHEA_MAX_PORTS; i++)
if (adapter->port[i])
- if (adapter->port[i]->logical_port_id == logical_port)
+ if (adapter->port[i]->logical_port_id == logical_port)
return adapter->port[i];
return NULL;
}
@@ -1695,6 +1695,7 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
{
if (skb->protocol == htons(ETH_P_IP)) {
const struct iphdr *iph = ip_hdr(skb);
+
/* IPv4 */
swqe->tx_control |= EHEA_SWQE_CRC
| EHEA_SWQE_IP_CHECKSUM
@@ -1705,13 +1706,12 @@ static void ehea_xmit2(struct sk_buff *skb, struct net_device *dev,
write_ip_start_end(swqe, skb);
if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
+ if ((iph->frag_off & IP_MF)
+ || (iph->frag_off & IP_OFFSET))
/* IP fragment, so don't change cs */
swqe->tx_control &= ~EHEA_SWQE_TCP_CHECKSUM;
else
write_udp_offset_end(swqe, skb);
-
} else if (iph->protocol == IPPROTO_TCP) {
write_tcp_offset_end(swqe, skb);
}
@@ -1739,6 +1739,7 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
if (skb->protocol == htons(ETH_P_IP)) {
const struct iphdr *iph = ip_hdr(skb);
+
/* IPv4 */
write_ip_start_end(swqe, skb);
@@ -1751,8 +1752,8 @@ static void ehea_xmit3(struct sk_buff *skb, struct net_device *dev,
write_tcp_offset_end(swqe, skb);
} else if (iph->protocol == IPPROTO_UDP) {
- if ((iph->frag_off & IP_MF) ||
- (iph->frag_off & IP_OFFSET))
+ if ((iph->frag_off & IP_MF)
+ || (iph->frag_off & IP_OFFSET))
/* IP fragment, so don't change cs */
swqe->tx_control |= EHEA_SWQE_CRC
| EHEA_SWQE_IMM_DATA_PRESENT;
@@ -2407,7 +2408,7 @@ static void __devinit logical_port_release(struct device *dev)
}
static int ehea_driver_sysfs_add(struct device *dev,
- struct device_driver *driver)
+ struct device_driver *driver)
{
int ret;
@@ -2424,7 +2425,7 @@ static int ehea_driver_sysfs_add(struct device *dev,
}
static void ehea_driver_sysfs_remove(struct device *dev,
- struct device_driver *driver)
+ struct device_driver *driver)
{
struct device_driver *drv = driver;
@@ -2453,7 +2454,7 @@ static struct device *ehea_register_port(struct ehea_port *port,
}
ret = device_create_file(&port->ofdev.dev, &dev_attr_log_port_id);
- if (ret) {
+ if (ret) {
ehea_error("failed to register attributes, ret=%d", ret);
goto out_unreg_of_dev;
}
@@ -2601,6 +2602,7 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
{
struct device_node *lhea_dn;
struct device_node *eth_dn = NULL;
+
const u32 *dn_log_port_id;
int i = 0;
@@ -2608,7 +2610,7 @@ static int ehea_setup_ports(struct ehea_adapter *adapter)
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
dn_log_port_id = of_get_property(eth_dn, "ibm,hea-port-no",
- NULL);
+ NULL);
if (!dn_log_port_id) {
ehea_error("bad device node: eth_dn name=%s",
eth_dn->full_name);
@@ -2648,7 +2650,7 @@ static struct device_node *ehea_get_eth_dn(struct ehea_adapter *adapter,
while ((eth_dn = of_get_next_child(lhea_dn, eth_dn))) {
dn_log_port_id = of_get_property(eth_dn, "ibm,hea-port-no",
- NULL);
+ NULL);
if (dn_log_port_id)
if (*dn_log_port_id == logical_port_id)
return eth_dn;
@@ -2789,7 +2791,7 @@ static int __devinit ehea_probe_adapter(struct ibmebus_dev *dev,
adapter->ebus_dev = dev;
adapter_handle = of_get_property(dev->ofdev.node, "ibm,hea-handle",
- NULL);
+ NULL);
if (adapter_handle)
adapter->handle = *adapter_handle;
diff --git a/drivers/net/ehea/ehea_qmr.c b/drivers/net/ehea/ehea_qmr.c
index f24a886..29eaa46 100644
--- a/drivers/net/ehea/ehea_qmr.c
+++ b/drivers/net/ehea/ehea_qmr.c
@@ -211,7 +211,7 @@ u64 ehea_destroy_cq_res(struct ehea_cq *cq, u64 force)
u64 hret;
u64 adapter_handle = cq->adapter->handle;
- /* deregister all previous registered pages */
+ /* deregister all previous registered pages */
hret = ehea_h_free_resource(adapter_handle, cq->fw_handle, force);
if (hret != H_SUCCESS)
return hret;
@@ -362,7 +362,7 @@ int ehea_destroy_eq(struct ehea_eq *eq)
if (hret != H_SUCCESS) {
ehea_error("destroy EQ failed");
return -EIO;
- }
+ }
return 0;
}
@@ -507,44 +507,44 @@ out_freemem:
u64 ehea_destroy_qp_res(struct ehea_qp *qp, u64 force)
{
- u64 hret;
- struct ehea_qp_init_attr *qp_attr = &qp->init_attr;
+ u64 hret;
+ struct ehea_qp_init_attr *qp_attr = &qp->init_attr;
- ehea_h_disable_and_get_hea(qp->adapter->handle, qp->fw_handle);
- hret = ehea_h_free_resource(qp->adapter->handle, qp->fw_handle, force);
- if (hret != H_SUCCESS)
- return hret;
+ ehea_h_disable_and_get_hea(qp->adapter->handle, qp->fw_handle);
+ hret = ehea_h_free_resource(qp->adapter->handle, qp->fw_handle, force);
+ if (hret != H_SUCCESS)
+ return hret;
- hw_queue_dtor(&qp->hw_squeue);
- hw_queue_dtor(&qp->hw_rqueue1);
+ hw_queue_dtor(&qp->hw_squeue);
+ hw_queue_dtor(&qp->hw_rqueue1);
- if (qp_attr->rq_count > 1)
- hw_queue_dtor(&qp->hw_rqueue2);
- if (qp_attr->rq_count > 2)
- hw_queue_dtor(&qp->hw_rqueue3);
- kfree(qp);
+ if (qp_attr->rq_count > 1)
+ hw_queue_dtor(&qp->hw_rqueue2);
+ if (qp_attr->rq_count > 2)
+ hw_queue_dtor(&qp->hw_rqueue3);
+ kfree(qp);
- return hret;
+ return hret;
}
int ehea_destroy_qp(struct ehea_qp *qp)
{
- u64 hret;
- if (!qp)
- return 0;
+ u64 hret;
+ if (!qp)
+ return 0;
- if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
- ehea_error_data(qp->adapter, qp->fw_handle);
- hret = ehea_destroy_qp_res(qp, FORCE_FREE);
- }
+ if ((hret = ehea_destroy_qp_res(qp, NORMAL_FREE)) == H_R_STATE) {
+ ehea_error_data(qp->adapter, qp->fw_handle);
+ hret = ehea_destroy_qp_res(qp, FORCE_FREE);
+ }
- if (hret != H_SUCCESS) {
- ehea_error("destroy QP failed");
- return -EIO;
- }
+ if (hret != H_SUCCESS) {
+ ehea_error("destroy QP failed");
+ return -EIO;
+ }
- return 0;
+ return 0;
}
int ehea_reg_kernel_mr(struct ehea_adapter *adapter, struct ehea_mr *mr)
^ permalink raw reply related
* Re: [PATCH 3/3] First cut at PReP support for arch/powerpc
From: Segher Boessenkool @ 2007-07-02 11:51 UTC (permalink / raw)
To: Gabriel Paubert; +Cc: linuxppc-dev, Paul Mackerras, David Gibson
In-Reply-To: <20070628100020.GA24215@iram.es>
>> + external-control;
>>
>> Really?
>
> Well, is anybody actually using eciwx/ecowx?
That's not the point -- the device tree should only
say "external-control" if the CPU actually supports
it; AFAIK, that's 601 only.
>> + pci@80000000 {
>> + device_type = "pci";
>> + compatible = "prep";
>>
>> Is that specific enough?
>
> On the MVME5100, actually the mapping is more CHRP like, and PCI I/O
> space is smaller and at a higher address.
Right, so it's not; "compatible" should specify the
model of PCI host bridge, instead.
>> What is the plan here -- have the bootwrapper build the
>> device tree / fill in the details from the residual data?
>
> I think so.
Right, good. What's the way forward then -- David, rename
this DTS file to <board name>.dts so you have something to
boot, and at the same time work on the bootwrapper?
> I might have some time to try a more recent kernel
> on MVME2400/2600 boards next week.
Great!
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 11:56 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Paul Mackerras, Guennadi Liakhovetski
In-Reply-To: <E6C54DC8-3152-4EE6-A1A1-389B41B23FC9@kernel.crashing.org>
>> Add of_register_i2c_devices(), which scans the children of the
>> specified
>> I2C adapter node, and registers them with the I2C code.
>>
>> Signed-off-by: Scott Wood <scottwood@freescale.com>
>> Signed-off-by: G. Liakhovetski <g.liakhovetski@gmx.de>
>
> I'm still against this patch since it means we are stating that I2C
> devices in the device tree must us the linux driver names. The two
> should be de-coupled.
Very much so. More comments as reply to the original post...
Segher
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Segher Boessenkool @ 2007-07-02 12:03 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0706292113240.4227@poirot.grange>
> + while ((node = of_get_next_child(adap_node, node))) {
of_for_each_child_node() or whatever it is called?
> + addr = of_get_property(node, "reg", &len);
> + if (!addr || len < sizeof(int) || *addr > 0xffff)
> + continue;
Addresses aren't 16 bit AFAIK?
> + name = of_get_property(node, "compatible", NULL);
> + if (!name)
> + name = node->name;
> + if (!name)
> + continue;
Look at "name" first, then look at "compatible", not
the other way around.
> + model = of_get_property(node, "model", NULL);
> + if (!model)
> + model = name;
No way. "model" and "name" have nothing in common
semantically.
> + /* FIXME: the i2c code should allow drivers to specify
> + * multiple match names; board code shouldn't need to
> + * know what driver will handle a given type.
> + */
This should be handled by the OF matching stuff, there
is no direct connection between device tree naming and
Linux driver naming. I don't want to see this patch
going in without this problem being fixed first.
Segher
^ permalink raw reply
* Re: [PATCH/RESENT] ehea: Whitespace cleanup
From: Jeff Garzik @ 2007-07-02 12:38 UTC (permalink / raw)
To: Jan-Bernd Themann
Cc: Thomas Klein, Jan-Bernd Themann, netdev, linux-kernel, linux-ppc,
Christoph Raisch, Marcus Eder, Stefan Roscher
In-Reply-To: <200707021300.46813.ossthema@de.ibm.com>
Jan-Bernd Themann wrote:
> This patch fixes several whitespace issues.
>
> Signed-off-by: Jan-Bernd Themann <themann@de.ibm.com>
applied
^ permalink raw reply
* Re: dtc: Remove bogus break statement
From: Jon Loeliger @ 2007-07-02 13:33 UTC (permalink / raw)
To: David Gibson; +Cc: linuxppc-dev, 5B
In-Reply-To: <20070628013231.GF15298@localhost.localdomain>
So, like, the other day David Gibson mumbled:
> Commit 0738774fcc34b78a708a127fb4b2f193d08c94ba introduced some
> incorrect indentation / bracketing in unflatten_tree(). By luck, the
> extra break statement intended to be within an if block, but actually
> afterwards has no semantic effect. Still, this patch gets rid of it
> for cleanliness.
>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Applied.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Jon Loeliger @ 2007-07-02 13:42 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <1183128803.30145.29.camel@weaponx.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
> Add a minimal install target
>
> Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
Applied with the following changes --amend'ed in as well:
> +install: dtc ftdump
> + $(INSTALL) -d $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 dtc $(DESTDIR)/$(BINDIR)
> + $(INSTALL) -m 755 ftdump $(DESTDIR)/$(BINDIR)
Don't put a slash after $(DESTDIR). You'll end up with a doulbe slash.
Andreas.
Thanks,
jdl
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Josh Boyer @ 2007-07-02 13:46 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev, david
In-Reply-To: <E1I5MAY-0005jS-Hk@jdl.com>
On Mon, 2007-07-02 at 08:42 -0500, Jon Loeliger wrote:
> So, like, the other day Josh Boyer mumbled:
> > Add a minimal install target
> >
> > Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
>
> Applied with the following changes --amend'ed in as well:
Great. Thanks Jon, saves me from having to send out yet another patch.
josh
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Sergei Shtylyov @ 2007-07-02 14:23 UTC (permalink / raw)
To: Jason Wessel
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Andrew Morton
In-Reply-To: <4689025C.8000001@windriver.com>
Hello.
Jason Wessel wrote:
>>> allmodconfig on powerpc (iMac g3) fails due to
>>> git-kgdb.patch. allmodconfig defaults should be changed?
>>> CC arch/powerpc/kernel/kgdb.o
>>> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB
>>> selected in .config. Unselect one of them.
>>> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
>>> make: *** [arch/powerpc/kernel] Blad 2
>> I'm not sure if this will work out but maybe it's worth to disable
>> XMON if KGDB is selected, like this?
>> config XMON
>> bool "Include xmon kernel debugger"
>> depends on DEBUGGER && !KGDB
> It did not seem that you can make a radio button / multi-select kernel
> config option unless the options are in the same Kconfig file. Given
> that xmon and kgdb are mutually exclusive at the moment.
> What Sergei mentioned is the fix that needs to be used for the time being.
> Attached is the patch I put in the for_mm branch in the linux-2.6-kgdb
> git tree.
> Jason.
> ------------------------------------------------------------------------
> xmon_or_kgdb.patch
> From: Jason Wessel <jason.wessel@windriver.com>
> Subject: [PATCH] Turn off xmon if kgdb is active on ppc and powerpc
> Xmon and kgdb are mutuall exclusive at the moment so xmon should be
> turned off in the kernel config options if kgdb selected. The case with "make allmodconfig" was failing and this patch addresses the problem.
> Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
> ---
> arch/powerpc/Kconfig.debug | 2 +-
> arch/ppc/Kconfig.debug | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
This patch does not seem complete as the #error that was tiggering has not
been deleleted from arch/powerpc/kernel/kgdb.c (and not it's useless)
WBR, Sergei
^ permalink raw reply
* Re: [PATCH v2] dtc: Add install makefile target
From: Jon Loeliger @ 2007-07-02 14:36 UTC (permalink / raw)
To: Josh Boyer; +Cc: linuxppc-dev, david
In-Reply-To: <1183384015.16523.0.camel@weaponx.rchland.ibm.com>
So, like, the other day Josh Boyer mumbled:
> > Applied with the following changes --amend'ed in as well:
>
> Great. Thanks Jon, saves me from having to send out yet another patch.
No problem. --amend is spiffy. And besides, we
really should avoid those "doulbe slash" [sic] issues!
jdl
PS -- Thankfully, we avoided any Angryflower Incidents! :-)
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Jason Wessel @ 2007-07-02 14:45 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Andrew Morton
In-Reply-To: <46890A52.6020201@ru.mvista.com>
Sergei Shtylyov wrote:
> Hello.
>
> Jason Wessel wrote:
>
>>>> allmodconfig on powerpc (iMac g3) fails due to
>>>> git-kgdb.patch. allmodconfig defaults should be changed?
>
>>>> CC arch/powerpc/kernel/kgdb.o
>>>> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB
>>>> selected in .config. Unselect one of them.
>>>> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
>>>> make: *** [arch/powerpc/kernel] Blad 2
>
> This patch does not seem complete as the #error that was tiggering
> has not been deleleted from arch/powerpc/kernel/kgdb.c (and not it's
> useless)
>
I suppose the argument could be made to remove the check in the compiled
file, but it does serve as a way to protect kgdb for now if someone
tries to hard compile in xmon and kgdb. Completely unpredictable
results will occur with the debugger unless some pieces are fixed. I
would rather make sure until that happens there is no way head down the
rat hole.
That issue aside would it be useful to have xmon+kgdb? After having
looked at the hook points for xmon, if a command was added to xmon to
provide an "detach" it would be easy enough to have kgdb and xmon in the
same kernel. Obviously only one or the other can be used at any given time.
Jason.
^ permalink raw reply
* Re: Anyone using QE UART mode?
From: Timur Tabi @ 2007-07-02 15:40 UTC (permalink / raw)
To: Ying Lin; +Cc: linuxppc-embedded
In-Reply-To: <8F798BFDA851B943B3A1B2510E9287850350A905@airmail.wirelessworld.airvananet.com>
Ying Lin wrote:
> How to enable TTY devices using QUICC Engine UCC UART Mode?
>
> Are Linux kernel patches enough to enable them? Or, additional
> programming required?
I'm working on a device driver for QE UART mode, but it's not working yet. The QE UART is
like the CPM UART, but I'm having troubel getting it to work.
It is *not* trivial, or even easy, to enabled. It's a full-blown UART driver that also
deals with the complexity of the QE.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* RE: Anyone using QE UART mode?
From: Ying Lin @ 2007-07-02 16:01 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-embedded
In-Reply-To: <46891C6B.3090507@freescale.com>
OK, the missing piece (UART driver) I am looking for is not available
yet. I will seek alternative solutions (create a simple UART driver, or
just wait).
Thanks for the information.=20
Ying=20
-----Original Message-----
From: Timur Tabi [mailto:timur@freescale.com]=20
Sent: Monday, July 02, 2007 11:40 AM
To: Ying Lin
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: Anyone using QE UART mode?
Ying Lin wrote:
> How to enable TTY devices using QUICC Engine UCC UART Mode?
>=20
> Are Linux kernel patches enough to enable them? Or, additional=20
> programming required?
I'm working on a device driver for QE UART mode, but it's not working
yet. The QE UART is=20
like the CPM UART, but I'm having troubel getting it to work.
It is *not* trivial, or even easy, to enabled. It's a full-blown UART
driver that also=20
deals with the complexity of the QE.
--=20
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* [PATCH] Consolidate PowerPC 750 cputable features
From: Josh Boyer @ 2007-07-02 16:06 UTC (permalink / raw)
To: linuxppc-dev
The 750 CPU_FTR macros have quite a bit of duplication in them. Consolidate
them to use CPU_FTRS_750 and only list the unique features for derivatives.
Signed-off-by: Josh Boyer <jwboyer@linux.vnet.ibm.com>
---
include/asm-powerpc/cputable.h | 26 ++++++--------------------
1 file changed, 6 insertions(+), 20 deletions(-)
--- linux-2.6.orig/include/asm-powerpc/cputable.h
+++ linux-2.6/include/asm-powerpc/cputable.h
@@ -225,26 +225,12 @@ extern void do_feature_fixups(unsigned l
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
CPU_FTR_PPC_LE)
-#define CPU_FTRS_750CL (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_HAS_HIGH_BATS | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750FX1 (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_NO_DPM | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750FX2 (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_NO_DPM | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750FX (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS | CPU_FTR_PPC_LE)
-#define CPU_FTRS_750GX (CPU_FTR_COMMON | \
- CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
- CPU_FTR_TAU | CPU_FTR_HPTE_TABLE | CPU_FTR_MAYBE_CAN_NAP | \
- CPU_FTR_DUAL_PLL_750FX | CPU_FTR_HAS_HIGH_BATS | CPU_FTR_PPC_LE)
+#define CPU_FTRS_750CL (CPU_FTRS_750 | CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_750FX1 (CPU_FTRS_750 | CPU_FTR_DUAL_PLL_750FX | CPU_FTR_NO_DPM)
+#define CPU_FTRS_750FX2 (CPU_FTRS_750 | CPU_FTR_NO_DPM)
+#define CPU_FTRS_750FX (CPU_FTRS_750 | CPU_FTR_DUAL_PLL_750FX | \
+ CPU_FTR_HAS_HIGH_BATS)
+#define CPU_FTRS_750GX (CPU_FTRS_750FX)
#define CPU_FTRS_7400_NOTAU (CPU_FTR_COMMON | \
CPU_FTR_MAYBE_CAN_DOZE | CPU_FTR_USE_TB | CPU_FTR_L2CR | \
CPU_FTR_ALTIVEC_COMP | CPU_FTR_HPTE_TABLE | \
^ permalink raw reply
* Re: 2.6.22-rc6-mm1
From: Jason Wessel @ 2007-07-02 13:49 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: kgdb-bugreport, linux-kernel, linuxppc-dev, Mariusz Kozlowski,
paulus, Andrew Morton
In-Reply-To: <4685010C.4000108@ru.mvista.com>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
Sergei Shtylyov wrote:
> Hello.
>
> Mariusz Kozlowski wrote:
>
>
>> allmodconfig on powerpc (iMac g3) fails due to
>> git-kgdb.patch. allmodconfig defaults should be changed?
>>
>
>
>> CC arch/powerpc/kernel/kgdb.o
>> arch/powerpc/kernel/kgdb.c:485:2: error: #error Both XMON and KGDB selected
>> in .config. Unselect one of them.
>> make[1]: *** [arch/powerpc/kernel/kgdb.o] Blad 1
>> make: *** [arch/powerpc/kernel] Blad 2
>>
>
> I'm not sure if this will work out but maybe it's worth to disable XMON if
> KGDB is selected, like this?
>
> config XMON
> bool "Include xmon kernel debugger"
> depends on DEBUGGER && !KGDB
>
>
It did not seem that you can make a radio button / multi-select kernel
config option unless the options are in the same Kconfig file. Given
that xmon and kgdb are mutually exclusive at the moment.
What Sergei mentioned is the fix that needs to be used for the time being.
Attached is the patch I put in the for_mm branch in the linux-2.6-kgdb
git tree.
Jason.
[-- Attachment #2: xmon_or_kgdb.patch --]
[-- Type: text/plain, Size: 1532 bytes --]
xmon_or_kgdb.patch
From: Jason Wessel <jason.wessel@windriver.com>
Subject: [PATCH] Turn off xmon if kgdb is active on ppc and powerpc
Xmon and kgdb are mutuall exclusive at the moment so xmon should be
turned off in the kernel config options if kgdb selected. The case with "make allmodconfig" was failing and this patch addresses the problem.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com>
---
arch/powerpc/Kconfig.debug | 2 +-
arch/ppc/Kconfig.debug | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
Index: linux-2.6-kgdb/arch/powerpc/Kconfig.debug
===================================================================
--- linux-2.6-kgdb.orig/arch/powerpc/Kconfig.debug
+++ linux-2.6-kgdb/arch/powerpc/Kconfig.debug
@@ -43,7 +43,7 @@ config HCALL_STATS
config XMON
bool "Include xmon kernel debugger"
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL && !KGDB
help
Include in-kernel hooks for the xmon kernel monitor/debugger.
Unless you are intending to debug the kernel, say N here.
Index: linux-2.6-kgdb/arch/ppc/Kconfig.debug
===================================================================
--- linux-2.6-kgdb.orig/arch/ppc/Kconfig.debug
+++ linux-2.6-kgdb/arch/ppc/Kconfig.debug
@@ -4,7 +4,7 @@ source "lib/Kconfig.debug"
config XMON
bool "Include xmon kernel debugger"
- depends on DEBUG_KERNEL
+ depends on DEBUG_KERNEL && !KGDB
help
Include in-kernel hooks for the xmon kernel monitor/debugger.
Unless you are intending to debug the kernel, say N here.
^ permalink raw reply
* Re: current-speed property in serial devices causes kernel panic
From: Kumar Gala @ 2007-07-02 16:46 UTC (permalink / raw)
To: Timur Tabi; +Cc: linuxppc-dev list, Arnd Bergmann
In-Reply-To: <4685DB63.7040705@freescale.com>
On Jun 29, 2007, at 11:26 PM, Timur Tabi wrote:
> I see this code in function of_platform_serial_setup():
>
> static int __devinit of_platform_serial_setup(struct of_device *ofdev,
> int type, struct uart_port
> *port)
> {
> struct resource resource;
> struct device_node *np = ofdev->node;
> const unsigned int *clk, *spd;
> int ret;
>
> memset(port, 0, sizeof *port);
> spd = of_get_property(np, "current-speed", NULL);
> ...
> port->custom_divisor = *clk / (16 * (*spd));
>
> return 0;
> }
>
> There is no check in this code to make sure spd is not null. And
> sure enough, in most DTS files, current-speed does not exist. So
> whenever this function is called on a node like this, the kernel
> panics.
I'm wondering why we set port->custom_divisor instead of setting port-
>speed. (plus the null check).
- k
^ permalink raw reply
* idr_get_new_above() limitation?
From: Hoang-Nam Nguyen @ 2007-07-02 17:19 UTC (permalink / raw)
To: linux-kernel, linuxppc-dev, openib-general, jim.houston
Cc: raisch, Stefan Roscher
Hello,
For ehca device driver we're intending to utilize
idr_get_new_above() and have written a test case, which I'm attaching
at the end. Basically it tries to get an idr token above a lower boundary
by calling idr_get_new_above() and then uses idr_find() to check if
the returned token can be found.
Here is our observation with 2.6.22-rc7 on ppc64:
Use lower boundary 0x3ffffffc
[root@xyz idr_bug]# insmod idr_test_mod.ko start=1073741820
insmod: error inserting 'idr_test_mod.ko': -1 Unknown symbol in module
[root@xyz idr_bug]# dmesg -c
i=3ffffffc token=3ffffffc t=000000003ffffffc
i=3ffffffd token=3ffffffd t=000000003ffffffd
i=3ffffffe token=3ffffffe t=000000003ffffffe
i=3fffffff token=3fffffff t=000000003fffffff
i=40000000 token=40000000 t=0000000000000000
Invalid object 0000000000000000. Expected 40000000
That means token 0x40000000 seems to be the "upper boundary" of idr_find().
However the behaviour is not consistent in that it was returned by
idr_get_new_above().
Looking at void *idr_find(struct idr *idp, int id)
{
int n;
struct idr_layer *p;
n = idp->layers * IDR_BITS;
p = idp->top;
/* Mask off upper bits we don't use for the search. */
id &= MAX_ID_MASK;
if (id >= (1 << n))
return NULL;
while (n > 0 && p) {
n -= IDR_BITS;
p = p->ary[(id >> n) & IDR_MASK];
}
return((void *)p);
}
we found that the if-condition has failed:
layers = 5
IDR_BITS = 6
n = 30
(id >= (1 << n)) = (0x40000000 >= 0x40000000) = 1
Since MAX_ID_MASK=0x7fffffff, I'm wondering if 0x40000000 is the actual
upper boundary. Any hints or suggestions are appreciated.
Thanks!
Nam
#include <linux/module.h>
#include <linux/idr.h>
MODULE_LICENSE("GPL");
int start_opt = 0x7e000000;
module_param_named(start, start_opt, int, 0);
MODULE_PARM_DESC(start,
"Start token for idr_get_new_above(). Default 0x7e000000");
static int __init idr_test_init(void)
{
DEFINE_IDR(idr);
int token, ret;
unsigned long i;
for (i = start_opt; i <= MAX_ID_MASK; i++) {
void * t;
if (!idr_pre_get(&idr, GFP_KERNEL)) {
printk(KERN_ERR "ERROR: Out of mem\n");
return -ENOENT;
}
ret = idr_get_new_above(&idr, (void*)i, start_opt, &token);
switch (ret) {
case 0:
t = idr_find(&idr, token);
printk(KERN_ERR "i=%lx token=%x t=%p\n", i, token, t);
if (t != (void*)i) {
printk(KERN_ERR "Invalid object %p. Expected %lx\n",
t, i);
return -ENOENT;
}
break;
case -EAGAIN:
i--;
printk("idr_get_new_above() ret=-EAGAIN\n");
break;
default:
printk(KERN_ERR "ERROR: Out of mem\n");
break;
}
}
/*
* return an error in any case since we don't need the module
* loaded anyway.
*/
return -ENOENT;
}
static void __exit idr_test_exit(void)
{
printk(KERN_ERR "module exit\n");
}
module_init(idr_test_init);
module_exit(idr_test_exit);
^ permalink raw reply
* [PATCH]: PCI Error Recovery: Symbios SCSI device driver
From: Linas Vepstas @ 2007-07-02 18:39 UTC (permalink / raw)
To: James.Bottomley, matthew, willy
Cc: Andrew Morton, linux-scsi, linux-kernel, linuxppc-dev,
Paul Mackerras, linux-pci
Various PCI bus errors can be signaled by newer PCI controllers.
This patch adds the PCI error recovery callbacks to the Symbios
SCSI device driver. The patch has been tested, and appears to
work well.
Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
----
Hi,
This patch has been bouncing around for a long time, and has made
appearences in various -mm trees since 2.6.something-teen. However,
it has never made it into mainline, and I'm starting to get concerned
that it will miss 2.6.23 as well.
There was some discussion, and I think I addressed all of the various
issues that came up. I'd really like to get this patch in, but am unclear
on exactly who to pester at this point. Matt Wilcox seems to be looking
for a job (???) and I am unable to git-clone James Bottmley's
git://kernel.org:/pub/scm/linux/kernel/git/jejb/scsi-misc-2.6.git
git tree; there's some error on the server side.
Linas.
drivers/scsi/sym53c8xx_2/sym_glue.c | 136 ++++++++++++++++++++++++++++++++++++
drivers/scsi/sym53c8xx_2/sym_glue.h | 4 +
drivers/scsi/sym53c8xx_2/sym_hipd.c | 6 +
3 files changed, 146 insertions(+)
Index: linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.c
===================================================================
--- linux-2.6.22-rc1.orig/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-04-25 22:08:32.000000000 -0500
+++ linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.c 2007-05-14 17:31:44.000000000 -0500
@@ -657,6 +657,10 @@ static irqreturn_t sym53c8xx_intr(int ir
unsigned long flags;
struct sym_hcb *np = (struct sym_hcb *)dev_id;
+ /* Avoid spinloop trying to handle interrupts on frozen device */
+ if (pci_channel_offline(np->s.device))
+ return IRQ_HANDLED;
+
if (DEBUG_FLAGS & DEBUG_TINY) printf_debug ("[");
spin_lock_irqsave(np->s.host->host_lock, flags);
@@ -726,6 +730,20 @@ static int sym_eh_handler(int op, char *
dev_warn(&cmd->device->sdev_gendev, "%s operation started.\n", opname);
+ /* We may be in an error condition because the PCI bus
+ * went down. In this case, we need to wait until the
+ * PCI bus is reset, the card is reset, and only then
+ * proceed with the scsi error recovery. There's no
+ * point in hurrying; take a leisurely wait.
+ */
+#define WAIT_FOR_PCI_RECOVERY 35
+ if (pci_channel_offline(np->s.device)) {
+ int finished_reset = wait_for_completion_timeout(
+ &np->s.io_reset_wait, WAIT_FOR_PCI_RECOVERY*HZ);
+ if (!finished_reset)
+ return SCSI_FAILED;
+ }
+
spin_lock_irq(host->host_lock);
/* This one is queued in some place -> to wait for completion */
FOR_EACH_QUEUED_ELEMENT(&np->busy_ccbq, qp) {
@@ -1510,6 +1528,7 @@ static struct Scsi_Host * __devinit sym_
np->maxoffs = dev->chip.offset_max;
np->maxburst = dev->chip.burst_max;
np->myaddr = dev->host_id;
+ init_completion(&np->s.io_reset_wait);
/*
* Edit its name.
@@ -1948,6 +1967,116 @@ static void __devexit sym2_remove(struct
attach_count--;
}
+/**
+ * sym2_io_error_detected() -- called when PCI error is detected
+ * @pdev: pointer to PCI device
+ * @state: current state of the PCI slot
+ */
+static pci_ers_result_t sym2_io_error_detected(struct pci_dev *pdev,
+ enum pci_channel_state state)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ /* If slot is permanently frozen, turn everything off */
+ if (state == pci_channel_io_perm_failure) {
+ sym2_remove(pdev);
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ init_completion(&np->s.io_reset_wait);
+ disable_irq(pdev->irq);
+ pci_disable_device(pdev);
+
+ /* Request a slot reset. */
+ return PCI_ERS_RESULT_NEED_RESET;
+}
+
+/**
+ * sym2_reset_workarounds -- hardware-specific work-arounds
+ *
+ * This routine is similar to sym_set_workarounds(), except
+ * that, at this point, we already know that the device was
+ * succesfully intialized at least once before, and so most
+ * of the steps taken there are un-needed here.
+ */
+static void sym2_reset_workarounds(struct pci_dev *pdev)
+{
+ u_char revision;
+ u_short status_reg;
+ struct sym_chip *chip;
+
+ pci_read_config_byte(pdev, PCI_CLASS_REVISION, &revision);
+ chip = sym_lookup_chip_table(pdev->device, revision);
+
+ /* Work around for errant bit in 895A, in a fashion
+ * similar to what is done in sym_set_workarounds().
+ */
+ pci_read_config_word(pdev, PCI_STATUS, &status_reg);
+ if (!(chip->features & FE_66MHZ) && (status_reg & PCI_STATUS_66MHZ)) {
+ status_reg = PCI_STATUS_66MHZ;
+ pci_write_config_word(pdev, PCI_STATUS, status_reg);
+ pci_read_config_word(pdev, PCI_STATUS, &status_reg);
+ }
+}
+
+/**
+ * sym2_io_slot_reset() -- called when the pci bus has been reset.
+ * @pdev: pointer to PCI device
+ *
+ * Restart the card from scratch.
+ */
+static pci_ers_result_t sym2_io_slot_reset(struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+
+ printk(KERN_INFO "%s: recovering from a PCI slot reset\n",
+ sym_name(np));
+
+ if (pci_enable_device(pdev)) {
+ printk(KERN_ERR "%s: Unable to enable afer PCI reset\n",
+ sym_name(np));
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ pci_set_master(pdev);
+ enable_irq(pdev->irq);
+
+ /* If the chip can do Memory Write Invalidate, enable it */
+ if (np->features & FE_WRIE) {
+ if (pci_set_mwi(pdev))
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+
+ /* Perform work-arounds, analogous to sym_set_workarounds() */
+ sym2_reset_workarounds(pdev);
+
+ /* Perform host reset only on one instance of the card */
+ if (PCI_FUNC (pdev->devfn) == 0) {
+ if (sym_reset_scsi_bus(np, 0)) {
+ printk(KERN_ERR "%s: Unable to reset scsi host\n",
+ sym_name(np));
+ return PCI_ERS_RESULT_DISCONNECT;
+ }
+ sym_start_up(np, 1);
+ }
+
+ return PCI_ERS_RESULT_RECOVERED;
+}
+
+/**
+ * sym2_io_resume() -- resume normal ops after PCI reset
+ * @pdev: pointer to PCI device
+ *
+ * Called when the error recovery driver tells us that its
+ * OK to resume normal operation. Use completion to allow
+ * halted scsi ops to resume.
+ */
+static void sym2_io_resume(struct pci_dev *pdev)
+{
+ struct sym_hcb *np = pci_get_drvdata(pdev);
+ complete_all(&np->s.io_reset_wait);
+}
+
static void sym2_get_signalling(struct Scsi_Host *shost)
{
struct sym_hcb *np = sym_get_hcb(shost);
@@ -2110,11 +2239,18 @@ static struct pci_device_id sym2_id_tabl
MODULE_DEVICE_TABLE(pci, sym2_id_table);
+static struct pci_error_handlers sym2_err_handler = {
+ .error_detected = sym2_io_error_detected,
+ .slot_reset = sym2_io_slot_reset,
+ .resume = sym2_io_resume,
+};
+
static struct pci_driver sym2_driver = {
.name = NAME53C8XX,
.id_table = sym2_id_table,
.probe = sym2_probe,
.remove = __devexit_p(sym2_remove),
+ .err_handler = &sym2_err_handler,
};
static int __init sym2_init(void)
Index: linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.h
===================================================================
--- linux-2.6.22-rc1.orig/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-04-25 22:08:32.000000000 -0500
+++ linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_glue.h 2007-05-14 17:31:44.000000000 -0500
@@ -40,6 +40,7 @@
#ifndef SYM_GLUE_H
#define SYM_GLUE_H
+#include <linux/completion.h>
#include <linux/delay.h>
#include <linux/ioport.h>
#include <linux/pci.h>
@@ -179,6 +180,9 @@ struct sym_shcb {
char chip_name[8];
struct pci_dev *device;
+ /* Waiter for clearing of frozen PCI bus */
+ struct completion io_reset_wait;
+
struct Scsi_Host *host;
void __iomem * ioaddr; /* MMIO kernel io address */
Index: linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_hipd.c
===================================================================
--- linux-2.6.22-rc1.orig/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-04-25 22:08:32.000000000 -0500
+++ linux-2.6.22-rc1/drivers/scsi/sym53c8xx_2/sym_hipd.c 2007-05-14 17:31:44.000000000 -0500
@@ -2809,6 +2809,12 @@ void sym_interrupt (struct sym_hcb *np)
dstat |= INB(np, nc_dstat);
istatc = INB(np, nc_istat);
istat |= istatc;
+
+ /* Prevent deadlock waiting on a condition that may never clear. */
+ if (unlikely(sist == 0xffff && dstat == 0xff)) {
+ if (pci_channel_offline(np->s.device))
+ return;
+ }
} while (istatc & (SIP|DIP));
if (DEBUG_FLAGS & DEBUG_TINY)
^ permalink raw reply
* RE: mpc8270 & Intel 82551ER on 2.6.17.14
From: Nicholas Hickman @ 2007-07-02 18:41 UTC (permalink / raw)
To: Pradyumna Sampath; +Cc: linuxppc-embedded
In-Reply-To: <f87351060706290112o407f75e5h9dffd9939ab80ef9@mail.gmail.com>
Pradyumna,
With the help of some others I have finally figured it out. I took a
step back and read the manual over and over along with debugging my
U-boot until it worked. My issue there was with the SIUMCR. Since I now
had that working in U-boot I moved on to the kernel where I found that I
was redefining the SIUMCR here:
arch/ppc/syslib/m82xx_pci.c=20
approx line 248
#elif defined CONFIG_PQ2FADS || MYBOARD
/*
* Setting required to enable IRQ1-IRQ7 (SIUMCR [DPPC]),
* and local bus for PCI (SIUMCR [LBPC]).
*/
immap->im_siu_conf.siu_82xx.sc_siumcr =3D
I was entering this routine since I was basing my config off of the
PQ2FADS board. I removed my board definition from the elif and
everything seems to be working fine.
Good luck!
-Nick
-----Original Message-----
From: Pradyumna Sampath [mailto:pradyumna.sampath@gmail.com]=20
Sent: Friday, June 29, 2007 4:12 AM
To: Nicholas Hickman
Cc: linuxppc-embedded@ozlabs.org
Subject: Re: mpc8270 & Intel 82551ER on 2.6.17.14
Hi Nicholas,
On 6/29/07, Nicholas Hickman <nhickman@dtechlabs.com> wrote:
>
>
> I am having trouble getting two 82551ER Ethernet controllers running=20
> in Linux. I am able to scan the PCI bus and see the devices and I was
> even able to program the EEPROM from U-boot.
>
> In the kernel I mapped the IRQ's through /arch/ppc/m82xx_pci.c. I've=20
> been using the e100 drive that comes with the 2.6.17.14 kernel and=20
> have also tried the driver directly from Intel. Both give the same=20
> results. The PCI scan shows the correct output for how the device
should be configured.
<snip..>
I have the same, exact same problem. But there are some of the
differences with the setup though. I have an MPC5200B and the other
difference is that I have a 2.6.21-rt3. However its the same ethernet
controller.
I am trying out a few things here, some of them being complete guesses.
But if I hit something, I will let this list know. Anyone else had
similar issues ? Request you to please holler.
regards
prady
--
htp://prady.livejournal.com
^ permalink raw reply
* Re: current-speed property in serial devices causes kernel panic
From: Timur Tabi @ 2007-07-02 20:01 UTC (permalink / raw)
To: linuxppc-dev list
In-Reply-To: <4685DB63.7040705@freescale.com>
Timur Tabi wrote:
> The kernel panic occurs only if I call of_platform_bus_probe().
FYI, thanks to Kumar, I found the problem: I had CONFIG_SERIAL_OF_PLATFORM enabled. This
causes of_serial.c to be compiled and loaded. On my platform, that wasn't doing anything
because initially I wasn't calling of_platform_bus_probe(). When I added that call to my
platform code, of_serial.c sprang to life and tried to probe the serial nodes in my device
tree. Apparently, of_serial.c is not compatible with fsl_soc.c.
--
Timur Tabi
Linux Kernel Developer @ Freescale
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Guennadi Liakhovetski @ 2007-07-02 20:11 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <00a85f152aa3547f0f0b4acd7954468a@kernel.crashing.org>
Hi Segher,
On Mon, 2 Jul 2007, Segher Boessenkool wrote:
> > + while ((node = of_get_next_child(adap_node, node))) {
>
> of_for_each_child_node() or whatever it is called?
Sure, would be nice, only I cannot find anything like that. I seem to
remember seeing a patch like that, but maybe I'me mistaken... Do you
remember details / can you find it?
> > + addr = of_get_property(node, "reg", &len);
> > + if (!addr || len < sizeof(int) || *addr > 0xffff)
> > + continue;
>
> Addresses aren't 16 bit AFAIK?
Maximum 10 bits. So, yes, it can become 0x3ff.
> > + name = of_get_property(node, "compatible", NULL);
> > + if (!name)
> > + name = node->name;
> > + if (!name)
> > + continue;
>
> Look at "name" first, then look at "compatible", not
> the other way around.
ok
> > + model = of_get_property(node, "model", NULL);
> > + if (!model)
> > + model = name;
>
> No way. "model" and "name" have nothing in common
> semantically.
ok
> > + /* FIXME: the i2c code should allow drivers to specify
> > + * multiple match names; board code shouldn't need to
> > + * know what driver will handle a given type.
> > + */
>
> This should be handled by the OF matching stuff, there
> is no direct connection between device tree naming and
> Linux driver naming. I don't want to see this patch
> going in without this problem being fixed first.
Right, this one is interesting. But this time I cannot even vaguely
remember seeing any "OF matching" code. I can only remember each driver
(or OF glue to a generic driver) parsing compatible of entries, like
legacy_serial.c. Or you mean we need to write such a matching layer?
AFAIK, i2c is not specified by OF standard. So, we are free to chose any
"compatible" fields for our dts. Which we then would need to match against
drivers. So, why not make this a 1-to-1 match? I.e.,
[OF] [I2C]
compatible <-> driver_name
model <-> type
Thanks
Guennadi
---
Guennadi Liakhovetski
^ permalink raw reply
* Re: Porting Linux to Xilinx ML410
From: khollan @ 2007-07-02 20:58 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <11328063.post@talk.nabble.com>
Im trying to mount the root file system off of compact flash and now I get
this happening during boot
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
any ideas what this is and how to fix it? I tried applying a patch that
talked about this but my version of xsysace.c already had those changes.
Thanks
Kevin
--
View this message in context: http://www.nabble.com/Porting-Linux-to-Xilinx-ML410-tf3989483.html#a11401755
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Porting Linux to Xilinx ML410
From: Grant Likely @ 2007-07-02 22:51 UTC (permalink / raw)
To: khollan; +Cc: linuxppc-embedded
In-Reply-To: <11401755.post@talk.nabble.com>
On 7/2/07, khollan <khollan@daktronics.com> wrote:
>
> Im trying to mount the root file system off of compact flash and now I get
> this happening during boot
>
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
> xsysace xsa: kicking stalled fsm; state=2 task=0 iter=1 dc=0
>
> any ideas what this is and how to fix it? I tried applying a patch that
> talked about this but my version of xsysace.c already had those changes.
It means the driver is not getting interrupts from the systemace
device, so it's reverting to (extremely slow) polling.
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* Re: idr_get_new_above() limitation?
From: Andrew Morton @ 2007-07-02 22:56 UTC (permalink / raw)
To: Hoang-Nam Nguyen
Cc: linux-kernel, openib-general, Stefan Roscher, linuxppc-dev,
raisch, jim.houston
In-Reply-To: <200707021919.27251.hnguyen@linux.vnet.ibm.com>
On Mon, 2 Jul 2007 19:19:26 +0200
Hoang-Nam Nguyen <hnguyen@linux.vnet.ibm.com> wrote:
> For ehca device driver we're intending to utilize
> idr_get_new_above() and have written a test case, which I'm attaching
> at the end. Basically it tries to get an idr token above a lower boundary
> by calling idr_get_new_above() and then uses idr_find() to check if
> the returned token can be found.
> Here is our observation with 2.6.22-rc7 on ppc64:
>
> Use lower boundary 0x3ffffffc
> [root@xyz idr_bug]# insmod idr_test_mod.ko start=1073741820
> insmod: error inserting 'idr_test_mod.ko': -1 Unknown symbol in module
> [root@xyz idr_bug]# dmesg -c
> i=3ffffffc token=3ffffffc t=000000003ffffffc
> i=3ffffffd token=3ffffffd t=000000003ffffffd
> i=3ffffffe token=3ffffffe t=000000003ffffffe
> i=3fffffff token=3fffffff t=000000003fffffff
> i=40000000 token=40000000 t=0000000000000000
> Invalid object 0000000000000000. Expected 40000000
>
> That means token 0x40000000 seems to be the "upper boundary" of idr_find().
> However the behaviour is not consistent in that it was returned by
> idr_get_new_above().
>
> Looking at void *idr_find(struct idr *idp, int id)
> {
> int n;
> struct idr_layer *p;
>
> n = idp->layers * IDR_BITS;
> p = idp->top;
>
> /* Mask off upper bits we don't use for the search. */
> id &= MAX_ID_MASK;
>
> if (id >= (1 << n))
> return NULL;
>
> while (n > 0 && p) {
> n -= IDR_BITS;
> p = p->ary[(id >> n) & IDR_MASK];
> }
> return((void *)p);
> }
> we found that the if-condition has failed:
> layers = 5
> IDR_BITS = 6
> n = 30
> (id >= (1 << n)) = (0x40000000 >= 0x40000000) = 1
>
> Since MAX_ID_MASK=0x7fffffff, I'm wondering if 0x40000000 is the actual
> upper boundary. Any hints or suggestions are appreciated.
Looks like a bug to me. Really an IDR tree on 32-bit should go all
the way up to 0xffffffff. Certainly up to 0x7fffffff. And the fact
that idr_find() disagrees with idr_get_new_above() is a big hint
that the code is getting it wrong.
^ permalink raw reply
* Re: [PATCH] powerpc: Add of_register_i2c_devices()
From: Scott Wood @ 2007-07-02 22:46 UTC (permalink / raw)
To: Guennadi Liakhovetski; +Cc: linuxppc-dev, Paul Mackerras
In-Reply-To: <Pine.LNX.4.60.0707022114020.3339@poirot.grange>
On Mon, Jul 02, 2007 at 10:11:04PM +0200, Guennadi Liakhovetski wrote:
> AFAIK, i2c is not specified by OF standard. So, we are free to chose any
> "compatible" fields for our dts. Which we then would need to match against
> drivers. So, why not make this a 1-to-1 match? I.e.,
> [OF] [I2C]
> compatible <-> driver_name
> model <-> type
If we do this, then the compatible field should probably be preceded with
"linux,", which would get stripped by of_register_i2c_devices(). This
would only be an interim measure until we can figure out some sort of
name registry via power.org. Once that happens, non-"linux," compatible
fields could be looked up in an OF-to-linux table, or there could be a
way for i2c devices to specify OF matches in addition to driver name.
-Scott
^ 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