Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip



On Saturday 30 June 2007 01:16:18 am Andrey Borzenkov wrote:
This patch fixes the 2.6.22 regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"

does not work, sorry.

Sigh ;-) Thanks for your patience in dealing with this.

[ 958.125710] 00:0a: SMCf010 not responding at SIR 0x2e800000100, FIR 0x2e8def5a6d4; auto-configuring
[ 958.132837] 00:0a: not responding at SIR 0x2e800000100, FIR 0xded782bc000002e8; swapping SIR/FIR and reconfiguring
[ 958.140954] 00:0a: responds at SIR 0x100000002e8, FIR 0xded782bc000002e8

This means that the SMCf010 device *did* respond, I think at the
FIR address 0x100. (I can't figure out the "right" way to print
those resource_size_t things, so I added some casts in the appended
patch.)

[ 524.426614] smsc_ircc_present(), addr 0x0100 - no device found!

But by the time the smsc_ircc2 driver got loaded, the device stopped
responding. That means something happened in between that messed it up.

as already mentioned, port 100 cannot work:

0100-013f : pcmcia_socket0
{pts/1}% sudo
cat /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
0x00000100 - 0x000003af
0x000003e0 - 0x000004ff
0x00000820 - 0x000008ff
0x00000a00 - 0x00000aff
0x00000c00 - 0x00000cf7

Well, the whole problem I'm trying to fix is that we aren't doing
resource allocation correctly. The BIOS has configured the IR
device to use port 0x100, and then something else came along and
decided to also use port 0x100.

It looks like the something else is the wlags49_h1_cs driver for
the PCMCIA card you have inserted. Can you temporarily remove that
card and driver and try the patch below? If the IR device works
without the wlags49_h1_cs driver, then we'll have to look at
wlags49_h1_cs to see whether it's doing something wrong.

Bjorn


[patch] PNP SMCf010 quirk: work around Toshiba Portege 4000 ACPI issues

When we enable the SMCf010 IR device, the Toshiba Portege 4000 BIOS claims
the device is working, but it really isn't configured correctly. The BIOS
*will* configure it, but only if we call _SRS after (1) reversing the order
of the SIR and FIR I/O port regions and (2) changing the IRQ from active-high
to active-low.

This patch addresses the 2.6.22 regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"

I tested this on a Portege 4000. The smsc-ircc2 driver correctly detects
the device, and "irattach irda0 -s && irdadump" shows transmitted and
received packets.

Signed-off-by: Bjorn Helgaas <bjorn.helgaas@xxxxxx>

Index: w/drivers/pnp/quirks.c
===================================================================
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.000000000 -0600
+++ w/drivers/pnp/quirks.c 2007-06-30 05:27:03.000000000 -0600
@@ -136,11 +136,10 @@

static void quirk_smc_enable(struct pnp_dev *dev)
{
- /*
- * If the BIOS left the device disabled, or it is enabled and
- * responding correctly, we're in good shape.
- */
- if (!dev->active || quirk_smc_fir_enabled(dev))
+ struct resource fir, sir, irq;
+
+ pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev))
return;

/*
@@ -152,16 +151,62 @@
* this. Fortunately, they do fix things up if we auto-configure
* the device using its _PRS and _SRS methods.
*/
- dev_err(&dev->dev, "%s device not responding, auto-configuring "
- "resources\n", dev->id->id);
+ dev_err(&dev->dev, "%s not responding at SIR 0x%lx, FIR 0x%lx; "
+ "auto-configuring\n", dev->id->id,
+ (unsigned long) pnp_port_start(dev, 0),
+ (unsigned long) pnp_port_start(dev, 1));

pnp_disable_dev(dev);
pnp_init_resource_table(&dev->res);
pnp_auto_config_dev(dev);
pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev)) {
+ dev_err(&dev->dev, "responds at SIR 0x%lx, FIR 0x%lx\n",
+ (unsigned long) pnp_port_start(dev, 0),
+ (unsigned long) pnp_port_start(dev, 1));
+ return;
+ }
+
+ /*
+ * The Toshiba Portege 4000 _CRS reports the FIR region first,
+ * followed by the SIR region. The BIOS will configure the bridge,
+ * but only if we call _SRS with SIR first, then FIR. It also
+ * reports the IRQ as active high, when it is really active low.
+ */
+ dev_err(&dev->dev, "not responding at SIR 0x%lx, FIR 0x%lx; "
+ "swapping SIR/FIR and reconfiguring\n",
+ (unsigned long) pnp_port_start(dev, 0),
+ (unsigned long) pnp_port_start(dev, 1));
+
+ /*
+ * Clear IORESOURCE_AUTO so pnp_activate_dev() doesn't reassign
+ * these resources any more.
+ */
+ fir = dev->res.port_resource[0];
+ sir = dev->res.port_resource[1];
+ fir.flags &= ~IORESOURCE_AUTO;
+ sir.flags &= ~IORESOURCE_AUTO;
+
+ irq = dev->res.irq_resource[0];
+ irq.flags &= ~IORESOURCE_AUTO;
+ irq.flags &= ~IORESOURCE_BITS;
+ irq.flags |= IORESOURCE_IRQ_LOWEDGE;
+
+ pnp_disable_dev(dev);
+ dev->res.port_resource[0] = sir;
+ dev->res.port_resource[1] = fir;
+ dev->res.irq_resource[0] = irq;
+ pnp_activate_dev(dev);
+
+ if (quirk_smc_fir_enabled(dev)) {
+ dev_err(&dev->dev, "responds at SIR 0x%lx, FIR 0x%lx\n",
+ (unsigned long) pnp_port_start(dev, 0),
+ (unsigned long) pnp_port_start(dev, 1));
+ return;
+ }

- if (!quirk_smc_fir_enabled(dev))
- dev_err(&dev->dev, "giving up; try \"smsc-ircc2.nopnp\"\n");
+ dev_err(&dev->dev, "giving up; try \"smsc-ircc2.nopnp\" and "
+ "email bjorn.helgaas@xxxxxx\n");
}


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/



Relevant Pages

  • Re: Call for testers, if_bge patch for BCM570x users
    ... "Should" your patch work against the BCM5788 chip? ... > with the bgedriver. ... > The bge driver programs the chip to autopoll the MII to check for link ...
    (freebsd-current)
  • Re: LAN91C and XSCALE
    ... I basically have the driver provided by SMSC, and I went into Lan91C111_Init.C and changed the base IO address to match that my platform uses. ... In my bootloader, I have written some low-level diagnostics to read the chip ID, set the MAC, etc., and all this seems to work so I believe the chip is where I think it is. ... Look at how your driver initializes the I/O address to know whether it wants physical or virtual uncached address (it's not hard to find: look for VirtualCopy using PAGE_PHYSICAL or not). ...
    (microsoft.public.windowsce.platbuilder)
  • [PATCH v5] Add Dallas DS1390/93/94 RTC chips
    ... This patch adds support for the Dallas DS1390/93/94 SPI RTC chip. ... This driver can also be built as a module. ...
    (Linux-Kernel)
  • [PATCH v6] Add Dallas DS1390/93/94 RTC chips
    ... This patch adds support for the Dallas DS1390/93/94 SPI RTC chip. ... This driver can also be built as a module. ...
    (Linux-Kernel)
  • [PATCH v4] Add Dallas DS1390/93/94 RTC chips
    ... This patch adds support for the Dallas DS1390/93/94 SPI RTC chip. ... This driver can also be built as a module. ...
    (Linux-Kernel)

Loading