Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 13 August 2007, Bjorn Helgaas wrote: > On Saturday 11 August 2007 12:39:35 pm Andrey Borzenkov wrote: > > This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable > > PnP by default; it is apparently enabled now and fails to activte IrDA > > completely. So it moves to post-2.6.22 regressions :) > > > > let me know which information you need > > > > [ 2192.666450] pnp: PnP ACPI init > > [ 2192.666589] ACPI: bus type pnp registered > > [ 2192.686035] pnp: Device 00:0a activated. > > [ 2192.686089] 00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; > > auto-configuring > > [ 2192.687610] pnp: Device 00:0a disabled. > > [ 2192.693179] pnp: Device 00:0a activated. > > [ 2192.693210] 00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping > > SIR/FIR and reconfiguring > > [ 2192.694720] pnp: Device 00:0a disabled. > > [ 2192.701232] pnp: Device 00:0a activated. > > [ 2192.701259] 00:0a: responds at SIR 0x2e8, FIR 0x100 > > [ 2192.709309] pnp: PnP ACPI: found 12 devices > > [ 2192.709351] ACPI: ACPI bus type pnp unregistered > > > > > > > > [ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge > > SMSC IrDA chip, pre-configuring device. > > [ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8. > > [ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8. > > [ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): > > LPC47N227 > > [ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: > > 7, mode: 0x0e > > [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 > > As of 2.6.23-rc2, we should have: > - probes for 8250 legacy devices (as in 2.6.21 and previous) > - smsc PNP probes turned off by default (2.6.21 and previous had no > PNP probes for smsc at all) > - some complicated PNP quirks for SMCf010 devices > > In other words, I think we're basically back where we started. Nope, it is a regression. > The 8250 > driver should find a ttyS3 device at 0x2e8, and it should claim those > ports, which will prevent smsc from claiming them. > This worked in 2.6.22 and does not work in 2.6.23. So something changed. I make a separate post about it because it is probably unrelated to smsc. > If you use "setserial /dev/ttyS3 none", the 8250 driver should release > the ports at 0x2e8, and then the smsc-ircc2 driver should be able to > load correctly. I think this is what we always had to do in the past, > right? > No; it "just worked". I do not even have setserial command ... installed one but this does not support "none" > If that doesn't work, try removing the body of quirk_smc_enable() in > drivers/pnp/quirks.c in addition. It's possible that the quirk changes > the config in a way that messes up the smsc-ircc2 probe. > If I unload 8250 smsc-ircc2 loads just fine. signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 13 August 2007, Bjorn Helgaas wrote: On Saturday 11 August 2007 12:39:35 pm Andrey Borzenkov wrote: This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP by default; it is apparently enabled now and fails to activte IrDA completely. So it moves to post-2.6.22 regressions :) let me know which information you need [ 2192.666450] pnp: PnP ACPI init [ 2192.666589] ACPI: bus type pnp registered [ 2192.686035] pnp: Device 00:0a activated. [ 2192.686089] 00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; auto-configuring [ 2192.687610] pnp: Device 00:0a disabled. [ 2192.693179] pnp: Device 00:0a activated. [ 2192.693210] 00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping SIR/FIR and reconfiguring [ 2192.694720] pnp: Device 00:0a disabled. [ 2192.701232] pnp: Device 00:0a activated. [ 2192.701259] 00:0a: responds at SIR 0x2e8, FIR 0x100 [ 2192.709309] pnp: PnP ACPI: found 12 devices [ 2192.709351] ACPI: ACPI bus type pnp unregistered [ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. [ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8. [ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8. [ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 [ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x0e [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 As of 2.6.23-rc2, we should have: - probes for 8250 legacy devices (as in 2.6.21 and previous) - smsc PNP probes turned off by default (2.6.21 and previous had no PNP probes for smsc at all) - some complicated PNP quirks for SMCf010 devices In other words, I think we're basically back where we started. Nope, it is a regression. The 8250 driver should find a ttyS3 device at 0x2e8, and it should claim those ports, which will prevent smsc from claiming them. This worked in 2.6.22 and does not work in 2.6.23. So something changed. I make a separate post about it because it is probably unrelated to smsc. If you use setserial /dev/ttyS3 none, the 8250 driver should release the ports at 0x2e8, and then the smsc-ircc2 driver should be able to load correctly. I think this is what we always had to do in the past, right? No; it just worked. I do not even have setserial command ... installed one but this does not support none If that doesn't work, try removing the body of quirk_smc_enable() in drivers/pnp/quirks.c in addition. It's possible that the quirk changes the config in a way that messes up the smsc-ircc2 probe. If I unload 8250 smsc-ircc2 loads just fine. signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Mon, Aug 13, 2007 at 10:09:46AM -0600, Bjorn Helgaas wrote: > > [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 > > As of 2.6.23-rc2, we should have: > - probes for 8250 legacy devices (as in 2.6.21 and previous) > - smsc PNP probes turned off by default (2.6.21 and previous had > no PNP probes for smsc at all) > - some complicated PNP quirks for SMCf010 devices > > In other words, I think we're basically back where we started. The > 8250 driver should find a ttyS3 device at 0x2e8, and it should > claim those ports, which will prevent smsc from claiming them. I use 8250.nr_uarts=1 appended to my kernel parameters on my laptop. Perfectly reliable workaround, but if it is possible to detect, then all the better! //Peter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 11 August 2007 12:39:35 pm Andrey Borzenkov wrote: > This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP > by default; it is apparently enabled now and fails to activte IrDA > completely. So it moves to post-2.6.22 regressions :) > > let me know which information you need > > [ 2192.666450] pnp: PnP ACPI init > [ 2192.666589] ACPI: bus type pnp registered > [ 2192.686035] pnp: Device 00:0a activated. > [ 2192.686089] 00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; > auto-configuring > [ 2192.687610] pnp: Device 00:0a disabled. > [ 2192.693179] pnp: Device 00:0a activated. > [ 2192.693210] 00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping > SIR/FIR and reconfiguring > [ 2192.694720] pnp: Device 00:0a disabled. > [ 2192.701232] pnp: Device 00:0a activated. > [ 2192.701259] 00:0a: responds at SIR 0x2e8, FIR 0x100 > [ 2192.709309] pnp: PnP ACPI: found 12 devices > [ 2192.709351] ACPI: ACPI bus type pnp unregistered > > > > [ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC > IrDA chip, pre-configuring device. > [ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8. > [ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8. > [ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): > LPC47N227 > [ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, > mode: 0x0e > [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 As of 2.6.23-rc2, we should have: - probes for 8250 legacy devices (as in 2.6.21 and previous) - smsc PNP probes turned off by default (2.6.21 and previous had no PNP probes for smsc at all) - some complicated PNP quirks for SMCf010 devices In other words, I think we're basically back where we started. The 8250 driver should find a ttyS3 device at 0x2e8, and it should claim those ports, which will prevent smsc from claiming them. If you use "setserial /dev/ttyS3 none", the 8250 driver should release the ports at 0x2e8, and then the smsc-ircc2 driver should be able to load correctly. I think this is what we always had to do in the past, right? If that doesn't work, try removing the body of quirk_smc_enable() in drivers/pnp/quirks.c in addition. It's possible that the quirk changes the config in a way that messes up the smsc-ircc2 probe. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 11 August 2007 12:39:35 pm Andrey Borzenkov wrote: This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP by default; it is apparently enabled now and fails to activte IrDA completely. So it moves to post-2.6.22 regressions :) let me know which information you need [ 2192.666450] pnp: PnP ACPI init [ 2192.666589] ACPI: bus type pnp registered [ 2192.686035] pnp: Device 00:0a activated. [ 2192.686089] 00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; auto-configuring [ 2192.687610] pnp: Device 00:0a disabled. [ 2192.693179] pnp: Device 00:0a activated. [ 2192.693210] 00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping SIR/FIR and reconfiguring [ 2192.694720] pnp: Device 00:0a disabled. [ 2192.701232] pnp: Device 00:0a activated. [ 2192.701259] 00:0a: responds at SIR 0x2e8, FIR 0x100 [ 2192.709309] pnp: PnP ACPI: found 12 devices [ 2192.709351] ACPI: ACPI bus type pnp unregistered [ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. [ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8. [ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8. [ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 [ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x0e [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 As of 2.6.23-rc2, we should have: - probes for 8250 legacy devices (as in 2.6.21 and previous) - smsc PNP probes turned off by default (2.6.21 and previous had no PNP probes for smsc at all) - some complicated PNP quirks for SMCf010 devices In other words, I think we're basically back where we started. The 8250 driver should find a ttyS3 device at 0x2e8, and it should claim those ports, which will prevent smsc from claiming them. If you use setserial /dev/ttyS3 none, the 8250 driver should release the ports at 0x2e8, and then the smsc-ircc2 driver should be able to load correctly. I think this is what we always had to do in the past, right? If that doesn't work, try removing the body of quirk_smc_enable() in drivers/pnp/quirks.c in addition. It's possible that the quirk changes the config in a way that messes up the smsc-ircc2 probe. Bjorn - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Mon, Aug 13, 2007 at 10:09:46AM -0600, Bjorn Helgaas wrote: [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 As of 2.6.23-rc2, we should have: - probes for 8250 legacy devices (as in 2.6.21 and previous) - smsc PNP probes turned off by default (2.6.21 and previous had no PNP probes for smsc at all) - some complicated PNP quirks for SMCf010 devices In other words, I think we're basically back where we started. The 8250 driver should find a ttyS3 device at 0x2e8, and it should claim those ports, which will prevent smsc from claiming them. I use 8250.nr_uarts=1 appended to my kernel parameters on my laptop. Perfectly reliable workaround, but if it is possible to detect, then all the better! //Peter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Bjorn Helgaas wrote: > 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. > This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP by default; it is apparently enabled now and fails to activte IrDA completely. So it moves to post-2.6.22 regressions :) let me know which information you need [ 2192.666450] pnp: PnP ACPI init [ 2192.666589] ACPI: bus type pnp registered [ 2192.686035] pnp: Device 00:0a activated. [ 2192.686089] 00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; auto-configuring [ 2192.687610] pnp: Device 00:0a disabled. [ 2192.693179] pnp: Device 00:0a activated. [ 2192.693210] 00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping SIR/FIR and reconfiguring [ 2192.694720] pnp: Device 00:0a disabled. [ 2192.701232] pnp: Device 00:0a activated. [ 2192.701259] 00:0a: responds at SIR 0x2e8, FIR 0x100 [ 2192.709309] pnp: PnP ACPI: found 12 devices [ 2192.709351] ACPI: ACPI bus type pnp unregistered [ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. [ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8. [ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8. [ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 [ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x0e [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Bjorn Helgaas wrote: 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. This stopped working again in 2.6.23-rc. In 2.6.22 we decided to disable PnP by default; it is apparently enabled now and fails to activte IrDA completely. So it moves to post-2.6.22 regressions :) let me know which information you need [ 2192.666450] pnp: PnP ACPI init [ 2192.666589] ACPI: bus type pnp registered [ 2192.686035] pnp: Device 00:0a activated. [ 2192.686089] 00:0a: SMCf010 not responding at SIR 0x100, FIR 0x2e8; auto-configuring [ 2192.687610] pnp: Device 00:0a disabled. [ 2192.693179] pnp: Device 00:0a activated. [ 2192.693210] 00:0a: not responding at SIR 0x100, FIR 0x2e8; swapping SIR/FIR and reconfiguring [ 2192.694720] pnp: Device 00:0a disabled. [ 2192.701232] pnp: Device 00:0a activated. [ 2192.701259] 00:0a: responds at SIR 0x2e8, FIR 0x100 [ 2192.709309] pnp: PnP ACPI: found 12 devices [ 2192.709351] ACPI: ACPI bus type pnp unregistered [ 2207.986550] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. [ 2207.986587] Activated ALi 1533 ISA bridge port 0x02e8. [ 2207.986602] Activated ALi 1533 ISA bridge port 0x02f8. [ 2207.986817] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227 [ 2207.986851] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x0e [ 2207.986873] smsc_ircc_present: can't get sir_base of 0x2e8 signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Andrew, can you apply the patch below for 2.6.22? It reverts
smsc-ircc2 to the old blind probing behavior. There's a lot of
infrastructure work I need to do before the PNP probe will be
reliable.
Thanks,
Bjorn
On Sunday 01 July 2007 01:08:16 am Andrey Borzenkov wrote:
> Bjorn Helgaas wrote:
> > I suspect that things will mostly work if you load the drivers in
> > the (smsc-ircc2, wlags49_h1_cs) order.
>
> yes
>
> > Then smsc-ircc2 has a chance
> > to reserve the resources before yenta and wlags49 get involved. But
> > of course, we can't rely on that workaround.
>
> yes :)
>
> > I think there's lots of work needed here -- make PNP reserve resources,
> > add smarter PNP quirk infrastructure so we can do things at _SRS-time,
> > add real Portege BIOS workaround, etc. Way more than we can do for
> > 2.6.22.
>
> yes :)
>
> > What do you think we need to get 2.6.22 out? I was thinking of a
> > stop-gap patch like the one below.
>
> I agree. I was about to suggest the same the very first time I have seen
> this issue.
>
> > I'm between trips and can't
> > really test it. In my one quick boot, it did find the IR device,
> > but irdadump didn't seem to do anything.
>
> I confirm that loading smsc-icc2 with nopnp (with your other two patches
> applied) works, finds SIR/FIR and irdadump shows data flowing.
[patch] smsc-ircc2: bypass PNP detection until we get the quirks worked out
Don't use PNP detection by default yet. We have some PNP and BIOS issues
to work out first.
Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off
disabled. We assign I/O ports originally assigned to the SMCf010 to a
PCMCIA device instead. We enable the SMCf010, configuring it to use
disjoint ports, but _SRS doesn't work correctly, so the device doesn't
work.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-30 21:00:06.0
-0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600
@@ -79,7 +79,7 @@
MODULE_DESCRIPTION("SMC IrCC SIR/FIR controller driver");
MODULE_LICENSE("GPL");
-static int smsc_nopnp;
+static int smsc_nopnp = 1;
module_param_named(nopnp, smsc_nopnp, bool, 0);
MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Bjorn Helgaas wrote:
[...]
>
> I suspect that things will mostly work if you load the drivers in
> the (smsc-ircc2, wlags49_h1_cs) order.
yes
> Then smsc-ircc2 has a chance
> to reserve the resources before yenta and wlags49 get involved. But
> of course, we can't rely on that workaround.
>
yes :)
> I think there's lots of work needed here -- make PNP reserve resources,
> add smarter PNP quirk infrastructure so we can do things at _SRS-time,
> add real Portege BIOS workaround, etc. Way more than we can do for
> 2.6.22.
>
yes :)
> What do you think we need to get 2.6.22 out? I was thinking of a
> stop-gap patch like the one below.
I agree. I was about to suggest the same the very first time I have seen
this issue.
> I'm between trips and can't
> really test it. In my one quick boot, it did find the IR device,
> but irdadump didn't seem to do anything.
>
I confirm that loading smsc-icc2 with nopnp (with your other two patches
applied) works, finds SIR/FIR and irdadump shows data flowing.
-andrey
>
>
> [patch] smsc-ircc2: bypass PNP detection until we get the quirks worked
> [out
>
> Don't use PNP detection by default yet. We have some PNP and BIOS issues
> to work out first.
>
> Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off
> disabled. We assign I/O ports originally assigned to the SMCf010 to a
> PCMCIA device instead. We enable the SMCf010, configuring it to use
> disjoint ports, but _SRS doesn't work correctly, so the device doesn't
> work.
>
> Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
>
> Index: w/drivers/net/irda/smsc-ircc2.c
> ===
> --- w.orig/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:06.0
> -0600
> +++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600
> @@ -79,7 +79,7 @@
> MODULE_DESCRIPTION("SMC IrCC SIR/FIR controller driver");
> MODULE_LICENSE("GPL");
>
> -static int smsc_nopnp;
> +static int smsc_nopnp = 1;
> module_param_named(nopnp, smsc_nopnp, bool, 0);
> MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Bjorn Helgaas wrote: [...] I suspect that things will mostly work if you load the drivers in the (smsc-ircc2, wlags49_h1_cs) order. yes Then smsc-ircc2 has a chance to reserve the resources before yenta and wlags49 get involved. But of course, we can't rely on that workaround. yes :) I think there's lots of work needed here -- make PNP reserve resources, add smarter PNP quirk infrastructure so we can do things at _SRS-time, add real Portege BIOS workaround, etc. Way more than we can do for 2.6.22. yes :) What do you think we need to get 2.6.22 out? I was thinking of a stop-gap patch like the one below. I agree. I was about to suggest the same the very first time I have seen this issue. I'm between trips and can't really test it. In my one quick boot, it did find the IR device, but irdadump didn't seem to do anything. I confirm that loading smsc-icc2 with nopnp (with your other two patches applied) works, finds SIR/FIR and irdadump shows data flowing. -andrey [patch] smsc-ircc2: bypass PNP detection until we get the quirks worked [out Don't use PNP detection by default yet. We have some PNP and BIOS issues to work out first. Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off disabled. We assign I/O ports originally assigned to the SMCf010 to a PCMCIA device instead. We enable the SMCf010, configuring it to use disjoint ports, but _SRS doesn't work correctly, so the device doesn't work. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Index: w/drivers/net/irda/smsc-ircc2.c === --- w.orig/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:06.0 -0600 +++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600 @@ -79,7 +79,7 @@ MODULE_DESCRIPTION(SMC IrCC SIR/FIR controller driver); MODULE_LICENSE(GPL); -static int smsc_nopnp; +static int smsc_nopnp = 1; module_param_named(nopnp, smsc_nopnp, bool, 0); MODULE_PARM_DESC(nopnp, Do not use PNP to detect controller settings); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Andrew, can you apply the patch below for 2.6.22? It reverts smsc-ircc2 to the old blind probing behavior. There's a lot of infrastructure work I need to do before the PNP probe will be reliable. Thanks, Bjorn On Sunday 01 July 2007 01:08:16 am Andrey Borzenkov wrote: Bjorn Helgaas wrote: I suspect that things will mostly work if you load the drivers in the (smsc-ircc2, wlags49_h1_cs) order. yes Then smsc-ircc2 has a chance to reserve the resources before yenta and wlags49 get involved. But of course, we can't rely on that workaround. yes :) I think there's lots of work needed here -- make PNP reserve resources, add smarter PNP quirk infrastructure so we can do things at _SRS-time, add real Portege BIOS workaround, etc. Way more than we can do for 2.6.22. yes :) What do you think we need to get 2.6.22 out? I was thinking of a stop-gap patch like the one below. I agree. I was about to suggest the same the very first time I have seen this issue. I'm between trips and can't really test it. In my one quick boot, it did find the IR device, but irdadump didn't seem to do anything. I confirm that loading smsc-icc2 with nopnp (with your other two patches applied) works, finds SIR/FIR and irdadump shows data flowing. [patch] smsc-ircc2: bypass PNP detection until we get the quirks worked out Don't use PNP detection by default yet. We have some PNP and BIOS issues to work out first. Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off disabled. We assign I/O ports originally assigned to the SMCf010 to a PCMCIA device instead. We enable the SMCf010, configuring it to use disjoint ports, but _SRS doesn't work correctly, so the device doesn't work. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Index: w/drivers/net/irda/smsc-ircc2.c === --- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-30 21:00:06.0 -0600 +++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600 @@ -79,7 +79,7 @@ MODULE_DESCRIPTION(SMC IrCC SIR/FIR controller driver); MODULE_LICENSE(GPL); -static int smsc_nopnp; +static int smsc_nopnp = 1; module_param_named(nopnp, smsc_nopnp, bool, 0); MODULE_PARM_DESC(nopnp, Do not use PNP to detect controller settings); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007 03:13:24 pm Andrey Borzenkov wrote:
> After some digging, it works now :) So the story:
>
> PCMCIA includes code for checking for free IO range(s)
> code is active only if CONFIG_ISA is defined
> CONFIG_ISA has this excellent help text:
> Find out whether you have ISA slots on your motherboard.
> and I was stupid enough to take this literally (having notebook I obviously
> do
> not have any slots at all)
I'm sorry I don't have time at the moment to do digging of my own.
But I don't think you should have to define CONFIG_ISA. I think
you hit the nail on the head in your last email -- PNP should be
reserving the resources of active devices.
The fact that PNP doesn't reserve them means PCMCIA is free to
claim them for itself. So I think PNP is mostly at fault here.
(Of course, we'll still have to work around the Portege BIOS
issue as well.)
> So after recompiling with CONFIG_ISA defined I now get
>
> [ 2254.136611] cs: IO port probe 0x100-0x3af: excluding 0x100-0x107
> 0x2e8-0x2ef 0x378-0x37f
> [ 2254.166638] cs: IO port probe 0x3e0-0x4ff: excluding 0x3f8-0x3ff
> 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
> [ 2254.194838] cs: IO port probe 0x820-0x8ff: clean.
> [ 2254.222401] cs: IO port probe 0xc00-0xcf7: clean.
> [ 2254.250056] cs: IO port probe 0xa00-0xaff: clean.
I suspect that things will mostly work if you load the drivers in
the (smsc-ircc2, wlags49_h1_cs) order. Then smsc-ircc2 has a chance
to reserve the resources before yenta and wlags49 get involved. But
of course, we can't rely on that workaround.
I think there's lots of work needed here -- make PNP reserve resources,
add smarter PNP quirk infrastructure so we can do things at _SRS-time,
add real Portege BIOS workaround, etc. Way more than we can do for
2.6.22.
What do you think we need to get 2.6.22 out? I was thinking of a
stop-gap patch like the one below. I'm between trips and can't
really test it. In my one quick boot, it did find the IR device,
but irdadump didn't seem to do anything.
[patch] smsc-ircc2: bypass PNP detection until we get the quirks worked out
Don't use PNP detection by default yet. We have some PNP and BIOS issues
to work out first.
Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off
disabled. We assign I/O ports originally assigned to the SMCf010 to a
PCMCIA device instead. We enable the SMCf010, configuring it to use
disjoint ports, but _SRS doesn't work correctly, so the device doesn't
work.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-30 21:00:06.0
-0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600
@@ -79,7 +79,7 @@
MODULE_DESCRIPTION("SMC IrCC SIR/FIR controller driver");
MODULE_LICENSE("GPL");
-static int smsc_nopnp;
+static int smsc_nopnp = 1;
module_param_named(nopnp, smsc_nopnp, bool, 0);
MODULE_PARM_DESC(nopnp, "Do not use PNP to detect controller settings");
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Michal Piotrowski pisze: > Hi, > > Bjorn Helgaas pisze: >> [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 fixes the 2.6.22 regression: >> "no irda0 interface (2.6.21 was OK), smsc does not find chip" > > Hmmm... > > 375 2007-06-29 14:24:47 6921mkkp"no irda0 interface > (2.6.21 was OK), smsc does not find chip" fixed, STATISTICS Bjorn Helgaas +1 > > Wasn't it fixed? > > commit 172d0496cd22c98ee2e4238821fa309c01685f3a > Author: Bjorn Helgaas <[EMAIL PROTECTED]> > Date: Wed Jun 27 14:09:52 2007 -0700 > [..] > This patch addresses part of the 2.6.22 regression: yup, my fault. Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi, Bjorn Helgaas pisze: > [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 fixes the 2.6.22 regression: > "no irda0 interface (2.6.21 was OK), smsc does not find chip" Hmmm... 375 2007-06-29 14:24:47 6921mkkp"no irda0 interface (2.6.21 was OK), smsc does not find chip" fixed, STATISTICS Bjorn Helgaas +1 Wasn't it fixed? commit 172d0496cd22c98ee2e4238821fa309c01685f3a Author: Bjorn Helgaas <[EMAIL PROTECTED]> Date: Wed Jun 27 14:09:52 2007 -0700 [..] This patch addresses part of 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. > Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Andrey Borzenkov wrote: > On Saturday 30 June 2007, Bjorn Helgaas wrote: > > 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.) > > Those can be 64 bit if CONFIG_RESOURCE_64BIT is set; so you probably should > cast to unsigned long long and use %llx. Or do it conditionally depending > on above macro. > > > 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. > After some digging, it works now :) So the story: PCMCIA includes code for checking for free IO range(s) code is active only if CONFIG_ISA is defined CONFIG_ISA has this excellent help text: Find out whether you have ISA slots on your motherboard. and I was stupid enough to take this literally (having notebook I obviously do not have any slots at all) So after recompiling with CONFIG_ISA defined I now get [ 2254.136611] cs: IO port probe 0x100-0x3af: excluding 0x100-0x107 0x2e8-0x2ef 0x378-0x37f [ 2254.166638] cs: IO port probe 0x3e0-0x4ff: excluding 0x3f8-0x3ff 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 [ 2254.194838] cs: IO port probe 0x820-0x8ff: clean. [ 2254.222401] cs: IO port probe 0xc00-0xcf7: clean. [ 2254.250056] cs: IO port probe 0xa00-0xaff: clean. (I wonder why this is repeated 3 times, but well ...) and smsc-ircc2 takes over ports 0x100 - 0x107 and is happy. THANK YOU! Bjorn, I believe last touch that is needed is to sort out printf issues, otherwise patch is fine here. -andrey signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Bjorn Helgaas wrote: > 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.) > Those can be 64 bit if CONFIG_RESOURCE_64BIT is set; so you probably should cast to unsigned long long and use %llx. Or do it conditionally depending on above macro. > 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. > That I already asked - how should PCMCIA subsystem know that some device requires fixed io port? Or for that matter - how should PnP know that some resource it believes is free is actually used by PCMCIA? > 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. > Yes, this works. I did not use patch below, because it works with original too of course. In this PCMCIA later sees that port range at 0x100 is already taken and selects another one: [ 693.694389] SMsC IrDA Controller found [ 693.694395] IrCC version 2.0, firport 0x100, sirport 0x2e8 dma=1, irq=5 [ 693.735620] No transceiver found. Defaulting to Fast pin select [ 693.757188] IrDA: Registered device irda0 [ 840.397539] Yenta: CardBus bridge found at :00:10.0 [12a3:ab01] [ 840.419345] Yenta: Using CSCINT to route CSC interrupts to PCI [ 840.441395] Yenta: Routing CardBus interrupts to PCI [ 840.463454] Yenta TI: socket :00:10.0, mfunc 0x0102, devctl 0x60 [ 840.713821] Yenta: ISA IRQ mask 0x, PCI irq 11 [ 840.736937] Socket status: 3059 [ 840.761016] Yenta: CardBus bridge found at :00:11.0 [1179:0001] [ 840.910480] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 [ 840.934571] Socket status: 3087 [ 840.959527] Yenta: CardBus bridge found at :00:11.1 [1179:0001] [ 841.110433] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 [ 841.135628] Socket status: 3087 [ 841.393023] pccard: PCMCIA card inserted into slot 0 [ 970.189560] wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere Systems, http://www.agere.com [ 970.212434] *** Modified for kernel 2.6 by Andrey Borzenkov <[EMAIL PROTECTED]> $Revision: 39 $ [ 970.235874] *** Station Mode (STA) Support: YES [ 970.259328] *** Access Point Mode (AP) Support: YES [ 1286.581694] cs: memory probe 0x0c-0x0f: excluding 0xc-0xcbfff 0xe-0xf [ 1286.608294] cs: memory probe 0x6000-0x60ff: clean. [ 1286.642101] cs: memory probe 0xa000-0xa0ff: clean. [ 1286.676160] pcmcia: registering new device pcmcia0.0 [ 1287.186722] eth0: PRI 31 variant 2 version 9.48 [ 1287.208487] eth0: NIC 5 variant 2 version 1.02 [ 1287.234616] eth0: Wireless, io_addr 0x180, irq 11, mac_address 00:02:2D:26:95:6C is it interesting to look at ports: 0100-0107 : smsc-ircc2 0170-0177 : :00:04.0 0170-0177 : libata 0180-01bf : pcmcia_socket0 notice that pcmcia_socket available resources do not change at all in this case and still list port range 100 - 3af. I do not think wlags driver has anything to do with it (directly). It just requests resource allocation from PCMCIA core. So either we have to mark resources of PnP devices reserved (even if devices are not active and no driver is loaded) or we need some way to force PnP to allocate different resources on device activation. Which means PCMCIA should somehow inform PnP that resources it allocated are in use. Anyway if you want to get a look - driver is available at http://arvidjaar.newmail.ru/wlags49.tar.bz2. -andrey signature.asc Description: This is a digitally signed message part.
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 0x2e80100, FIR
> 0x2e8def5a6d4; auto-configuring
> [ 958.132837] 00:0a: not responding at SIR 0x2e80100, FIR
> 0xded782bc02e8; swapping SIR/FIR and reconfiguring
> [ 958.140954] 00:0a: responds at SIR 0x10002e8, FIR 0xded782bc02e8
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
> 0x0100 - 0x03af
> 0x03e0 - 0x04ff
> 0x0820 - 0x08ff
> 0x0a00 - 0x0aff
> 0x0c00 - 0x0cf7
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 <[EMAIL PROTECTED]>
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-30 05:27:03.0 -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, "%s device not responding, auto-configuring "
- "resources\n", dev->id->id);
+ dev_err(>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(>res);
pnp_auto_config_dev(dev);
pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev)) {
+ dev_err(>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, "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
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Bjorn Helgaas wrote:
> [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 fixes the 2.6.22 regression:
> "no irda0 interface (2.6.21 was OK), smsc does not find chip"
>
does not work, sorry.
[ 958.107142] ACPI: bus type pnp registered
[ 958.125652] pnp: Device 00:0a activated.
[ 958.125710] 00:0a: SMCf010 not responding at SIR 0x2e80100, FIR
0x2e8def5a6d4; auto-configuring
[ 958.127243] pnp: Device 00:0a disabled.
[ 958.132808] pnp: Device 00:0a activated.
[ 958.132837] 00:0a: not responding at SIR 0x2e80100, FIR
0xded782bc02e8; swapping SIR/FIR and reconfiguring
[ 958.134350] pnp: Device 00:0a disabled.
[ 958.140926] pnp: Device 00:0a activated.
[ 958.140954] 00:0a: responds at SIR 0x10002e8, FIR 0xded782bc02e8
[ 958.148707] pnp: PnP ACPI: found 12 devices
and loading smsc_ircc2
[ 524.423280] pnp: Device 00:0a activated.
[ 524.426614] smsc_ircc_present(), addr 0x0100 - no device found!
[ 524.426614] pnp: Device 00:0a disabled.
as already mentioned, port 100 cannot work:
0100-013f : pcmcia_socket0
{pts/1}% sudo
cat /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
0x0100 - 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
additinally I get these warnings during compile (and output is bogus):
/home/bor/src/linux-git/drivers/pnp/quirks.c: In function ‘quirk_smc_enable’:
/home/bor/src/linux-git/drivers/pnp/quirks.c:154: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:154: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 6 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:163: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 4 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:163: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:174: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 4 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:174: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:199: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 4 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:199: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
-andrey
> 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 <[EMAIL PROTECTED]>
>
> Index: w/drivers/pnp/quirks.c
> ===
> --- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
> +++ w/drivers/pnp/quirks.c2007-06-29 19:28:02.0 -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,58 @@
>* this. Fortunately, they do fix things up if we auto-configure
>* the device using its _PRS and _SRS methods.
>*/
> - dev_err(>dev, "%s device not responding, auto-configuring "
> - "resources\n", dev->id->id);
> + dev_err(>dev, "%s not responding at SIR 0x%llx, FIR 0x%llx; "
> + "auto-configuring\n", dev->id->id,
> + pnp_port_start(dev, 0), pnp_port_start(dev, 1));
>
> pnp_disable_dev(dev);
> pnp_init_resource_table(>res);
> pnp_auto_config_dev(dev);
> pnp_activate_dev(dev);
> + if (quirk_smc_fir_enabled(dev)) {
> + dev_err(>dev, "responds at SIR 0x%llx, FIR 0x%llx\n",
> + pnp_port_start(dev, 0), 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
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Bjorn Helgaas wrote:
[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 fixes the 2.6.22 regression:
no irda0 interface (2.6.21 was OK), smsc does not find chip
does not work, sorry.
[ 958.107142] ACPI: bus type pnp registered
[ 958.125652] pnp: Device 00:0a activated.
[ 958.125710] 00:0a: SMCf010 not responding at SIR 0x2e80100, FIR
0x2e8def5a6d4; auto-configuring
[ 958.127243] pnp: Device 00:0a disabled.
[ 958.132808] pnp: Device 00:0a activated.
[ 958.132837] 00:0a: not responding at SIR 0x2e80100, FIR
0xded782bc02e8; swapping SIR/FIR and reconfiguring
[ 958.134350] pnp: Device 00:0a disabled.
[ 958.140926] pnp: Device 00:0a activated.
[ 958.140954] 00:0a: responds at SIR 0x10002e8, FIR 0xded782bc02e8
[ 958.148707] pnp: PnP ACPI: found 12 devices
and loading smsc_ircc2
[ 524.423280] pnp: Device 00:0a activated.
[ 524.426614] smsc_ircc_present(), addr 0x0100 - no device found!
[ 524.426614] pnp: Device 00:0a disabled.
as already mentioned, port 100 cannot work:
0100-013f : pcmcia_socket0
{pts/1}% sudo
cat /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
0x0100 - 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
additinally I get these warnings during compile (and output is bogus):
/home/bor/src/linux-git/drivers/pnp/quirks.c: In function ‘quirk_smc_enable’:
/home/bor/src/linux-git/drivers/pnp/quirks.c:154: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:154: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 6 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:163: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 4 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:163: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:174: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 4 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:174: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:199: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 4 has
type ‘resource_size_t’
/home/bor/src/linux-git/drivers/pnp/quirks.c:199: warning: format ‘%llx’
expects type ‘long long unsigned int’, but argument 5 has
type ‘resource_size_t’
-andrey
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 [EMAIL PROTECTED]
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c2007-06-29 19:28:02.0 -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,58 @@
* 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%llx, FIR 0x%llx;
+ auto-configuring\n, dev-id-id,
+ pnp_port_start(dev, 0), 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%llx, FIR 0x%llx\n,
+ pnp_port_start(dev, 0), 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
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 0x2e80100, FIR
0x2e8def5a6d4; auto-configuring
[ 958.132837] 00:0a: not responding at SIR 0x2e80100, FIR
0xded782bc02e8; swapping SIR/FIR and reconfiguring
[ 958.140954] 00:0a: responds at SIR 0x10002e8, FIR 0xded782bc02e8
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
0x0100 - 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
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 [EMAIL PROTECTED]
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-30 05:27:03.0 -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];
+
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Bjorn Helgaas wrote: 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.) Those can be 64 bit if CONFIG_RESOURCE_64BIT is set; so you probably should cast to unsigned long long and use %llx. Or do it conditionally depending on above macro. 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. That I already asked - how should PCMCIA subsystem know that some device requires fixed io port? Or for that matter - how should PnP know that some resource it believes is free is actually used by PCMCIA? 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. Yes, this works. I did not use patch below, because it works with original too of course. In this PCMCIA later sees that port range at 0x100 is already taken and selects another one: [ 693.694389] SMsC IrDA Controller found [ 693.694395] IrCC version 2.0, firport 0x100, sirport 0x2e8 dma=1, irq=5 [ 693.735620] No transceiver found. Defaulting to Fast pin select [ 693.757188] IrDA: Registered device irda0 [ 840.397539] Yenta: CardBus bridge found at :00:10.0 [12a3:ab01] [ 840.419345] Yenta: Using CSCINT to route CSC interrupts to PCI [ 840.441395] Yenta: Routing CardBus interrupts to PCI [ 840.463454] Yenta TI: socket :00:10.0, mfunc 0x0102, devctl 0x60 [ 840.713821] Yenta: ISA IRQ mask 0x, PCI irq 11 [ 840.736937] Socket status: 3059 [ 840.761016] Yenta: CardBus bridge found at :00:11.0 [1179:0001] [ 840.910480] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 [ 840.934571] Socket status: 3087 [ 840.959527] Yenta: CardBus bridge found at :00:11.1 [1179:0001] [ 841.110433] Yenta: ISA IRQ mask 0x04b8, PCI irq 11 [ 841.135628] Socket status: 3087 [ 841.393023] pccard: PCMCIA card inserted into slot 0 [ 970.189560] wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere Systems, http://www.agere.com [ 970.212434] *** Modified for kernel 2.6 by Andrey Borzenkov [EMAIL PROTECTED] $Revision: 39 $ [ 970.235874] *** Station Mode (STA) Support: YES [ 970.259328] *** Access Point Mode (AP) Support: YES [ 1286.581694] cs: memory probe 0x0c-0x0f: excluding 0xc-0xcbfff 0xe-0xf [ 1286.608294] cs: memory probe 0x6000-0x60ff: clean. [ 1286.642101] cs: memory probe 0xa000-0xa0ff: clean. [ 1286.676160] pcmcia: registering new device pcmcia0.0 [ 1287.186722] eth0: PRI 31 variant 2 version 9.48 [ 1287.208487] eth0: NIC 5 variant 2 version 1.02 [ 1287.234616] eth0: Wireless, io_addr 0x180, irq 11, mac_address 00:02:2D:26:95:6C is it interesting to look at ports: 0100-0107 : smsc-ircc2 0170-0177 : :00:04.0 0170-0177 : libata 0180-01bf : pcmcia_socket0 notice that pcmcia_socket available resources do not change at all in this case and still list port range 100 - 3af. I do not think wlags driver has anything to do with it (directly). It just requests resource allocation from PCMCIA core. So either we have to mark resources of PnP devices reserved (even if devices are not active and no driver is loaded) or we need some way to force PnP to allocate different resources on device activation. Which means PCMCIA should somehow inform PnP that resources it allocated are in use. Anyway if you want to get a look - driver is available at http://arvidjaar.newmail.ru/wlags49.tar.bz2. -andrey signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007, Andrey Borzenkov wrote: On Saturday 30 June 2007, Bjorn Helgaas wrote: 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.) Those can be 64 bit if CONFIG_RESOURCE_64BIT is set; so you probably should cast to unsigned long long and use %llx. Or do it conditionally depending on above macro. 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. After some digging, it works now :) So the story: PCMCIA includes code for checking for free IO range(s) code is active only if CONFIG_ISA is defined CONFIG_ISA has this excellent help text: Find out whether you have ISA slots on your motherboard. and I was stupid enough to take this literally (having notebook I obviously do not have any slots at all) So after recompiling with CONFIG_ISA defined I now get [ 2254.136611] cs: IO port probe 0x100-0x3af: excluding 0x100-0x107 0x2e8-0x2ef 0x378-0x37f [ 2254.166638] cs: IO port probe 0x3e0-0x4ff: excluding 0x3f8-0x3ff 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 [ 2254.194838] cs: IO port probe 0x820-0x8ff: clean. [ 2254.222401] cs: IO port probe 0xc00-0xcf7: clean. [ 2254.250056] cs: IO port probe 0xa00-0xaff: clean. (I wonder why this is repeated 3 times, but well ...) and smsc-ircc2 takes over ports 0x100 - 0x107 and is happy. THANK YOU! Bjorn, I believe last touch that is needed is to sort out printf issues, otherwise patch is fine here. -andrey signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi, Bjorn Helgaas pisze: [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 fixes the 2.6.22 regression: no irda0 interface (2.6.21 was OK), smsc does not find chip Hmmm... 375 2007-06-29 14:24:47 6921mkkpno irda0 interface (2.6.21 was OK), smsc does not find chip fixed, STATISTICS Bjorn Helgaas +1 Wasn't it fixed? commit 172d0496cd22c98ee2e4238821fa309c01685f3a Author: Bjorn Helgaas [EMAIL PROTECTED] Date: Wed Jun 27 14:09:52 2007 -0700 [..] This patch addresses part of 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. Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Michal Piotrowski pisze: Hi, Bjorn Helgaas pisze: [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 fixes the 2.6.22 regression: no irda0 interface (2.6.21 was OK), smsc does not find chip Hmmm... 375 2007-06-29 14:24:47 6921mkkpno irda0 interface (2.6.21 was OK), smsc does not find chip fixed, STATISTICS Bjorn Helgaas +1 Wasn't it fixed? commit 172d0496cd22c98ee2e4238821fa309c01685f3a Author: Bjorn Helgaas [EMAIL PROTECTED] Date: Wed Jun 27 14:09:52 2007 -0700 [..] This patch addresses part of the 2.6.22 regression: yup, my fault. Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 30 June 2007 03:13:24 pm Andrey Borzenkov wrote: After some digging, it works now :) So the story: PCMCIA includes code for checking for free IO range(s) code is active only if CONFIG_ISA is defined CONFIG_ISA has this excellent help text: Find out whether you have ISA slots on your motherboard. and I was stupid enough to take this literally (having notebook I obviously do not have any slots at all) I'm sorry I don't have time at the moment to do digging of my own. But I don't think you should have to define CONFIG_ISA. I think you hit the nail on the head in your last email -- PNP should be reserving the resources of active devices. The fact that PNP doesn't reserve them means PCMCIA is free to claim them for itself. So I think PNP is mostly at fault here. (Of course, we'll still have to work around the Portege BIOS issue as well.) So after recompiling with CONFIG_ISA defined I now get [ 2254.136611] cs: IO port probe 0x100-0x3af: excluding 0x100-0x107 0x2e8-0x2ef 0x378-0x37f [ 2254.166638] cs: IO port probe 0x3e0-0x4ff: excluding 0x3f8-0x3ff 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7 [ 2254.194838] cs: IO port probe 0x820-0x8ff: clean. [ 2254.222401] cs: IO port probe 0xc00-0xcf7: clean. [ 2254.250056] cs: IO port probe 0xa00-0xaff: clean. I suspect that things will mostly work if you load the drivers in the (smsc-ircc2, wlags49_h1_cs) order. Then smsc-ircc2 has a chance to reserve the resources before yenta and wlags49 get involved. But of course, we can't rely on that workaround. I think there's lots of work needed here -- make PNP reserve resources, add smarter PNP quirk infrastructure so we can do things at _SRS-time, add real Portege BIOS workaround, etc. Way more than we can do for 2.6.22. What do you think we need to get 2.6.22 out? I was thinking of a stop-gap patch like the one below. I'm between trips and can't really test it. In my one quick boot, it did find the IR device, but irdadump didn't seem to do anything. [patch] smsc-ircc2: bypass PNP detection until we get the quirks worked out Don't use PNP detection by default yet. We have some PNP and BIOS issues to work out first. Sample problem on a Toshiba Portege 4000: the SMCf010 device is handed off disabled. We assign I/O ports originally assigned to the SMCf010 to a PCMCIA device instead. We enable the SMCf010, configuring it to use disjoint ports, but _SRS doesn't work correctly, so the device doesn't work. Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED] Index: w/drivers/net/irda/smsc-ircc2.c === --- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-30 21:00:06.0 -0600 +++ w/drivers/net/irda/smsc-ircc2.c 2007-06-30 21:00:08.0 -0600 @@ -79,7 +79,7 @@ MODULE_DESCRIPTION(SMC IrCC SIR/FIR controller driver); MODULE_LICENSE(GPL); -static int smsc_nopnp; +static int smsc_nopnp = 1; module_param_named(nopnp, smsc_nopnp, bool, 0); MODULE_PARM_DESC(nopnp, Do not use PNP to detect controller settings); - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
[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 fixes 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 <[EMAIL PROTECTED]>
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-29 19:28:02.0 -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,58 @@
* this. Fortunately, they do fix things up if we auto-configure
* the device using its _PRS and _SRS methods.
*/
- dev_err(>dev, "%s device not responding, auto-configuring "
- "resources\n", dev->id->id);
+ dev_err(>dev, "%s not responding at SIR 0x%llx, FIR 0x%llx; "
+ "auto-configuring\n", dev->id->id,
+ pnp_port_start(dev, 0), pnp_port_start(dev, 1));
pnp_disable_dev(dev);
pnp_init_resource_table(>res);
pnp_auto_config_dev(dev);
pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev)) {
+ dev_err(>dev, "responds at SIR 0x%llx, FIR 0x%llx\n",
+ pnp_port_start(dev, 0), 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, "not responding at SIR 0x%llx, FIR 0x%llx; "
+ "swapping SIR/FIR and reconfiguring\n",
+ pnp_port_start(dev, 0), 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, "responds at SIR 0x%llx, FIR 0x%llx\n",
+ pnp_port_start(dev, 0), pnp_port_start(dev, 1));
+ return;
+ }
- if (!quirk_smc_fir_enabled(dev))
- dev_err(>dev, "giving up; try \"smsc-ircc2.nopnp\"\n");
+ dev_err(>dev, "giving up; try \"smsc-ircc2.nopnp\" and "
+ "email [EMAIL PROTECTED]");
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
[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 fixes 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 [EMAIL PROTECTED]
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-29 19:28:02.0 -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,58 @@
* 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%llx, FIR 0x%llx;
+ auto-configuring\n, dev-id-id,
+ pnp_port_start(dev, 0), 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%llx, FIR 0x%llx\n,
+ pnp_port_start(dev, 0), 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%llx, FIR 0x%llx;
+ swapping SIR/FIR and reconfiguring\n,
+ pnp_port_start(dev, 0), 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%llx, FIR 0x%llx\n,
+ pnp_port_start(dev, 0), 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 [EMAIL PROTECTED]);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Andrey,
Can you try the following patch? It applies on top of the previous
two patches, and it is enough to make the driver find the device on
my Portege 4000. Unfortunately, I can't tell whether it really works
because I don't have a clue about how to make two IR devices talk
to each other.
Bjorn
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-27 20:57:47.0 -0600
@@ -136,11 +136,11 @@
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))
+ unsigned int irq;
+ unsigned long flags;
+
+ pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev))
return;
/*
@@ -159,9 +159,34 @@
pnp_init_resource_table(>res);
pnp_auto_config_dev(dev);
pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev))
+ return;
+
+ /*
+* The Toshiba Portege 4000 reports the IRQ as active high,
+* edge-triggered, but the device only seems to work when we
+* program it as something else.
+*/
+ irq = pnp_irq(dev, 0);
+ flags = pnp_irq_flags(dev, 0);
+ pnp_disable_dev(dev);
+ dev->res.irq_resource[0].start = irq;
+ dev->res.irq_resource[0].end = irq;
+ flags &= ~IORESOURCE_AUTO;
+ if ((flags & IORESOURCE_BITS) == IORESOURCE_IRQ_HIGHEDGE) {
+ flags &= ~IORESOURCE_BITS;
+ flags |= IORESOURCE_IRQ_LOWEDGE;
+ dev_err(>dev, "still not responding, changing high-edge "
+ "IRQ to low-edge\n");
+ }
+ dev->res.irq_resource[0].flags = flags;
+ pnp_activate_dev(dev);
+
+ if (quirk_smc_fir_enabled(dev))
+ return;
- if (!quirk_smc_fir_enabled(dev))
- dev_err(>dev, "giving up; try \"smsc-ircc2.nopnp\"\n");
+ dev_err(>dev, "giving up; try \"smsc-ircc2.nopnp\" and "
+ "email [EMAIL PROTECTED]");
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Andrey,
Can you try the following patch? It applies on top of the previous
two patches, and it is enough to make the driver find the device on
my Portege 4000. Unfortunately, I can't tell whether it really works
because I don't have a clue about how to make two IR devices talk
to each other.
Bjorn
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-27 20:07:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-27 20:57:47.0 -0600
@@ -136,11 +136,11 @@
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))
+ unsigned int irq;
+ unsigned long flags;
+
+ pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev))
return;
/*
@@ -159,9 +159,34 @@
pnp_init_resource_table(dev-res);
pnp_auto_config_dev(dev);
pnp_activate_dev(dev);
+ if (quirk_smc_fir_enabled(dev))
+ return;
+
+ /*
+* The Toshiba Portege 4000 reports the IRQ as active high,
+* edge-triggered, but the device only seems to work when we
+* program it as something else.
+*/
+ irq = pnp_irq(dev, 0);
+ flags = pnp_irq_flags(dev, 0);
+ pnp_disable_dev(dev);
+ dev-res.irq_resource[0].start = irq;
+ dev-res.irq_resource[0].end = irq;
+ flags = ~IORESOURCE_AUTO;
+ if ((flags IORESOURCE_BITS) == IORESOURCE_IRQ_HIGHEDGE) {
+ flags = ~IORESOURCE_BITS;
+ flags |= IORESOURCE_IRQ_LOWEDGE;
+ dev_err(dev-dev, still not responding, changing high-edge
+ IRQ to low-edge\n);
+ }
+ dev-res.irq_resource[0].flags = flags;
+ pnp_activate_dev(dev);
+
+ if (quirk_smc_fir_enabled(dev))
+ 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 [EMAIL PROTECTED]);
}
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 16 June 2007 10:38:56 am Andrey Borzenkov wrote:
> it appears that quirk is not even applied because PnP tells us device is not
> active:
>
> [ 571.118483] pnp: PnP ACPI init
> [ 571.118611] ACPI: bus type pnp registered
> [ 571.158828] quirk_smc_enable: active = 0
> [ 571.182090] pnp: PnP ACPI: found 12 devices
Yup. That could probably be improved.
_CRS definitely reports SIR and FIR backwards from most platforms.
I can make the device talk by configuring it "by hand," e.g.,
# cd /sys/bus/pnp/devices/00:0a
# echo "set io 0x2e8-0x2ef io 0x100-0x107 irq 5 dma 1" > resources
# echo activate > resources
# ~/smsc
smsc_dump: 0x24 0xfe UART1 config
smsc_dump: 0x25 0xba SIR base (0x2e8)
smsc_dump: 0x28 0x45 UART IRQ
smsc_dump: 0x2b 0x20 FIR base (0x100)
smsc_dump: 0x2c 0x01 FIR DMA
smsc_dump: 0x0c 0x0e IRDA mode
smsc_dump: 0x07 0x50 powerdown mode
smsc_dump: 0x0a 0x40 toshiba mystery
# ~/inb 0x100 8 0x100
selecting bank 3 (fir at 0x100)
0x0100: 0x10 0xb8 0xf2 0x00 0x51 0x00 0x00 0x03
("smsc" and "inb" are little test programs (attached). "smsc" dumps
the SIO configuration, and "inb" dumps I/O ports. In this case,
I'm looking at the FIR ports, and the values there are what smsc-ircc2
expects.)
Seems like it should be simple to do the same thing automatically
in the driver or a quirk, but I haven't been able to get that to work.
I'll be out of the office most of the time from now until July 5, but
I'll get back to this when I return.
Bjorn
P.S. "reboot" doesn't seem to work on my box. I tried "reboot=b",
"reboot=c", "reboot=h", and none of them seems to work. Does it work
on yours?
/*
* Dump SMSC/LPC47N227 config, typically IRDA config
*/
#include
#include
#include
/**
Keys. They should work with every SMsC SIO
**/
#define SMSCSIO_CFGACCESSKEY 0x55
#define SMSCSIO_CFGEXITKEY 0xaa
/*
* Generic SIO Flat (!?) *
*/
/* Register 0x0d */
#define SMSCSIOFLAT_DEVICEID_REG0x0d
/* Register 0x0c */
#define SMSCSIOFLAT_UARTMODE0C_REG0x0c
#define SMSCSIOFLAT_UART2MODE_MASK 0x38
#define SMSCSIOFLAT_UART2MODE_VAL_COM 0x00
#define SMSCSIOFLAT_UART2MODE_VAL_IRDA 0x08
#define SMSCSIOFLAT_UART2MODE_VAL_ASKIR 0x10
/* Register 0x25 */
#define SMSCSIOFLAT_UART2BASEADDR_REG 0x25
/* Register 0x2b */
#define SMSCSIOFLAT_FIRBASEADDR_REG0x2b
/* Register 0x2c */
#define SMSCSIOFLAT_FIRDMASELECT_REG 0x2c
#define SMSCSIOFLAT_FIRDMASELECT_MASK 0x0f
/* Register 0x28 */
#define SMSCSIOFLAT_UARTIRQSELECT_REG 0x28
#define SMSCSIOFLAT_UART2IRQSELECT_MASK 0x0f
#define SMSCSIOFLAT_UART1IRQSELECT_MASK 0xf0
#define SMSCSIOFLAT_UARTIRQSELECT_VAL_NONE 0x00
/*
* LPC47N227 *
*/
#define LPC47N227_CFGACCESSKEY 0x55
#define LPC47N227_CFGEXITKEY 0xaa
/* Register 0x00 */
#define LPC47N227_FDCPOWERVALIDCONF_REG 0x00
#define LPC47N227_FDCPOWER_MASK 0x08
#define LPC47N227_VALID_MASK0x80
/* Register 0x02 */
#define LPC47N227_UART12POWER_REG0x02
#define LPC47N227_UART1POWERDOWN_MASK 0x08
#define LPC47N227_UART2POWERDOWN_MASK 0x80
/* Register 0x07 */
#define LPC47N227_APMBOOTDRIVE_REG0x07
#define LPC47N227_PARPORT2AUTOPWRDOWN_MASK 0x10 /* auto power down on if set */
#define LPC47N227_UART2AUTOPWRDOWN_MASK 0x20 /* auto power down on if set */
#define LPC47N227_UART1AUTOPWRDOWN_MASK 0x40 /* auto power down on if set */
/* Register 0x0c */
#define LPC47N227_UARTMODE0C_REG0x0c
#define LPC47N227_UART2MODE_MASK 0x38
#define LPC47N227_UART2MODE_VAL_COM 0x00
#define LPC47N227_UART2MODE_VAL_IRDA 0x08
#define LPC47N227_UART2MODE_VAL_ASKIR 0x10
/* Register 0x0d */
#define LPC47N227_DEVICEID_REG 0x0d
#define LPC47N227_DEVICEID_DEFVAL 0x5a
/* Register 0x0e */
#define LPC47N227_REVISIONID_REG0x0e
/* Register 0x25 */
#define LPC47N227_UART2BASEADDR_REG 0x25
/* Register 0x28 */
#define LPC47N227_UARTIRQSELECT_REG 0x28
#define LPC47N227_UART2IRQSELECT_MASK 0x0f
#define LPC47N227_UART1IRQSELECT_MASK 0xf0
#define LPC47N227_UARTIRQSELECT_VAL_NONE 0x00
/* Register 0x2b */
#define LPC47N227_FIRBASEADDR_REG0x2b
/* Register 0x2c */
#define LPC47N227_FIRDMASELECT_REG0x2c
#define LPC47N227_FIRDMASELECT_MASK 0x0f
#define LPC47N227_FIRDMASELECT_VAL_DMA1 0x01 /* 47n227 has three dma channels */
#define LPC47N227_FIRDMASELECT_VAL_DMA2 0x02
#define LPC47N227_FIRDMASELECT_VAL_DMA3 0x03
#define LPC47N227_FIRDMASELECT_VAL_NONE 0x0f
static inline unsigned int smsc_read(unsigned int port, unsigned int reg)
{
outb(reg, port);
return inb(port + 1);
}
static inline void smsc_write(unsigned int port, unsigned int reg, unsigned int
val)
{
outb(reg, port);
outb(val, port + 1);
}
static void smsc_dump(unsigned int iobase)
{
unsigned char val;
outb(LPC47N227_CFGACCESSKEY, iobase); // enter configuration state
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Saturday 16 June 2007 10:38:56 am Andrey Borzenkov wrote:
it appears that quirk is not even applied because PnP tells us device is not
active:
[ 571.118483] pnp: PnP ACPI init
[ 571.118611] ACPI: bus type pnp registered
[ 571.158828] quirk_smc_enable: active = 0
[ 571.182090] pnp: PnP ACPI: found 12 devices
Yup. That could probably be improved.
_CRS definitely reports SIR and FIR backwards from most platforms.
I can make the device talk by configuring it by hand, e.g.,
# cd /sys/bus/pnp/devices/00:0a
# echo set io 0x2e8-0x2ef io 0x100-0x107 irq 5 dma 1 resources
# echo activate resources
# ~/smsc
smsc_dump: 0x24 0xfe UART1 config
smsc_dump: 0x25 0xba SIR base (0x2e8)
smsc_dump: 0x28 0x45 UART IRQ
smsc_dump: 0x2b 0x20 FIR base (0x100)
smsc_dump: 0x2c 0x01 FIR DMA
smsc_dump: 0x0c 0x0e IRDA mode
smsc_dump: 0x07 0x50 powerdown mode
smsc_dump: 0x0a 0x40 toshiba mystery
# ~/inb 0x100 8 0x100
selecting bank 3 (fir at 0x100)
0x0100: 0x10 0xb8 0xf2 0x00 0x51 0x00 0x00 0x03
(smsc and inb are little test programs (attached). smsc dumps
the SIO configuration, and inb dumps I/O ports. In this case,
I'm looking at the FIR ports, and the values there are what smsc-ircc2
expects.)
Seems like it should be simple to do the same thing automatically
in the driver or a quirk, but I haven't been able to get that to work.
I'll be out of the office most of the time from now until July 5, but
I'll get back to this when I return.
Bjorn
P.S. reboot doesn't seem to work on my box. I tried reboot=b,
reboot=c, reboot=h, and none of them seems to work. Does it work
on yours?
/*
* Dump SMSC/LPC47N227 config, typically IRDA config
*/
#include stdio.h
#include stdlib.h
#include sys/io.h
/**
Keys. They should work with every SMsC SIO
**/
#define SMSCSIO_CFGACCESSKEY 0x55
#define SMSCSIO_CFGEXITKEY 0xaa
/*
* Generic SIO Flat (!?) *
*/
/* Register 0x0d */
#define SMSCSIOFLAT_DEVICEID_REG0x0d
/* Register 0x0c */
#define SMSCSIOFLAT_UARTMODE0C_REG0x0c
#define SMSCSIOFLAT_UART2MODE_MASK 0x38
#define SMSCSIOFLAT_UART2MODE_VAL_COM 0x00
#define SMSCSIOFLAT_UART2MODE_VAL_IRDA 0x08
#define SMSCSIOFLAT_UART2MODE_VAL_ASKIR 0x10
/* Register 0x25 */
#define SMSCSIOFLAT_UART2BASEADDR_REG 0x25
/* Register 0x2b */
#define SMSCSIOFLAT_FIRBASEADDR_REG0x2b
/* Register 0x2c */
#define SMSCSIOFLAT_FIRDMASELECT_REG 0x2c
#define SMSCSIOFLAT_FIRDMASELECT_MASK 0x0f
/* Register 0x28 */
#define SMSCSIOFLAT_UARTIRQSELECT_REG 0x28
#define SMSCSIOFLAT_UART2IRQSELECT_MASK 0x0f
#define SMSCSIOFLAT_UART1IRQSELECT_MASK 0xf0
#define SMSCSIOFLAT_UARTIRQSELECT_VAL_NONE 0x00
/*
* LPC47N227 *
*/
#define LPC47N227_CFGACCESSKEY 0x55
#define LPC47N227_CFGEXITKEY 0xaa
/* Register 0x00 */
#define LPC47N227_FDCPOWERVALIDCONF_REG 0x00
#define LPC47N227_FDCPOWER_MASK 0x08
#define LPC47N227_VALID_MASK0x80
/* Register 0x02 */
#define LPC47N227_UART12POWER_REG0x02
#define LPC47N227_UART1POWERDOWN_MASK 0x08
#define LPC47N227_UART2POWERDOWN_MASK 0x80
/* Register 0x07 */
#define LPC47N227_APMBOOTDRIVE_REG0x07
#define LPC47N227_PARPORT2AUTOPWRDOWN_MASK 0x10 /* auto power down on if set */
#define LPC47N227_UART2AUTOPWRDOWN_MASK 0x20 /* auto power down on if set */
#define LPC47N227_UART1AUTOPWRDOWN_MASK 0x40 /* auto power down on if set */
/* Register 0x0c */
#define LPC47N227_UARTMODE0C_REG0x0c
#define LPC47N227_UART2MODE_MASK 0x38
#define LPC47N227_UART2MODE_VAL_COM 0x00
#define LPC47N227_UART2MODE_VAL_IRDA 0x08
#define LPC47N227_UART2MODE_VAL_ASKIR 0x10
/* Register 0x0d */
#define LPC47N227_DEVICEID_REG 0x0d
#define LPC47N227_DEVICEID_DEFVAL 0x5a
/* Register 0x0e */
#define LPC47N227_REVISIONID_REG0x0e
/* Register 0x25 */
#define LPC47N227_UART2BASEADDR_REG 0x25
/* Register 0x28 */
#define LPC47N227_UARTIRQSELECT_REG 0x28
#define LPC47N227_UART2IRQSELECT_MASK 0x0f
#define LPC47N227_UART1IRQSELECT_MASK 0xf0
#define LPC47N227_UARTIRQSELECT_VAL_NONE 0x00
/* Register 0x2b */
#define LPC47N227_FIRBASEADDR_REG0x2b
/* Register 0x2c */
#define LPC47N227_FIRDMASELECT_REG0x2c
#define LPC47N227_FIRDMASELECT_MASK 0x0f
#define LPC47N227_FIRDMASELECT_VAL_DMA1 0x01 /* 47n227 has three dma channels */
#define LPC47N227_FIRDMASELECT_VAL_DMA2 0x02
#define LPC47N227_FIRDMASELECT_VAL_DMA3 0x03
#define LPC47N227_FIRDMASELECT_VAL_NONE 0x0f
static inline unsigned int smsc_read(unsigned int port, unsigned int reg)
{
outb(reg, port);
return inb(port + 1);
}
static inline void smsc_write(unsigned int port, unsigned int reg, unsigned int
val)
{
outb(reg, port);
outb(val, port + 1);
}
static void smsc_dump(unsigned int iobase)
{
unsigned char val;
outb(LPC47N227_CFGACCESSKEY, iobase); // enter configuration state
val =
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 15 June 2007, Bjorn Helgaas wrote: > On Friday 15 June 2007 07:44:41 am Andrey Borzenkov wrote: > > On Friday 15 June 2007, Bjorn Helgaas wrote: > > > Hi Andrey, > > > > > > If you have a chance, can you try the attached two patches? The > > > smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk > > > patch makes the nw8000/nc8000 work, too. > > > > > > I've heard rumors that Windows does basically the same thing as the > > > smsc-quirk patch, so I think there's a chance it might make your > > > Toshiba work as well. > > > > > > I sent the smsc-preconfig patch to Andrew this morning. I'm going > > > to do some more testing other HP laptops before sending him the > > > smsc-quirk patch. > > > > Does not work, sorry. (Patches were taken from your another mails but I > > assume they are the same). Does not work even if I unload > > PCMCIA/yenta_socket to "free" resources. > > > > I am out of ideas but am ready to test patches if someone has. > > Thanks for testing that. it appears that quirk is not even applied because PnP tells us device is not active: [ 571.118483] pnp: PnP ACPI init [ 571.118611] ACPI: bus type pnp registered [ 571.158828] quirk_smc_enable: active = 0 [ 571.182090] pnp: PnP ACPI: found 12 devices so this patch effectively did not change anything. well, that's correct so far, it really is not active after system boot. May be, quirk should be applied when device is being activated, not when device is being enumerated? > I bought a Portege 4000 so I can work > on this without bothering you. I'll let you know if I make any > progress on it. > > Bjorn signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 15 June 2007, Bjorn Helgaas wrote: On Friday 15 June 2007 07:44:41 am Andrey Borzenkov wrote: On Friday 15 June 2007, Bjorn Helgaas wrote: Hi Andrey, If you have a chance, can you try the attached two patches? The smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk patch makes the nw8000/nc8000 work, too. I've heard rumors that Windows does basically the same thing as the smsc-quirk patch, so I think there's a chance it might make your Toshiba work as well. I sent the smsc-preconfig patch to Andrew this morning. I'm going to do some more testing other HP laptops before sending him the smsc-quirk patch. Does not work, sorry. (Patches were taken from your another mails but I assume they are the same). Does not work even if I unload PCMCIA/yenta_socket to free resources. I am out of ideas but am ready to test patches if someone has. Thanks for testing that. it appears that quirk is not even applied because PnP tells us device is not active: [ 571.118483] pnp: PnP ACPI init [ 571.118611] ACPI: bus type pnp registered [ 571.158828] quirk_smc_enable: active = 0 [ 571.182090] pnp: PnP ACPI: found 12 devices so this patch effectively did not change anything. well, that's correct so far, it really is not active after system boot. May be, quirk should be applied when device is being activated, not when device is being enumerated? I bought a Portege 4000 so I can work on this without bothering you. I'll let you know if I make any progress on it. Bjorn signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 15 June 2007 07:44:41 am Andrey Borzenkov wrote: > On Friday 15 June 2007, Bjorn Helgaas wrote: > > Hi Andrey, > > > > If you have a chance, can you try the attached two patches? The > > smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk > > patch makes the nw8000/nc8000 work, too. > > > > I've heard rumors that Windows does basically the same thing as the > > smsc-quirk patch, so I think there's a chance it might make your > > Toshiba work as well. > > > > I sent the smsc-preconfig patch to Andrew this morning. I'm going > > to do some more testing other HP laptops before sending him the > > smsc-quirk patch. > > > > Does not work, sorry. (Patches were taken from your another mails but I > assume > they are the same). Does not work even if I unload PCMCIA/yenta_socket > to "free" resources. > > I am out of ideas but am ready to test patches if someone has. Thanks for testing that. I bought a Portege 4000 so I can work on this without bothering you. I'll let you know if I make any progress on it. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 15 June 2007, Bjorn Helgaas wrote: > Hi Andrey, > > If you have a chance, can you try the attached two patches? The > smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk > patch makes the nw8000/nc8000 work, too. > > I've heard rumors that Windows does basically the same thing as the > smsc-quirk patch, so I think there's a chance it might make your > Toshiba work as well. > > I sent the smsc-preconfig patch to Andrew this morning. I'm going > to do some more testing other HP laptops before sending him the > smsc-quirk patch. > Does not work, sorry. (Patches were taken from your another mails but I assume they are the same). Does not work even if I unload PCMCIA/yenta_socket to "free" resources. I am out of ideas but am ready to test patches if someone has. signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 15 June 2007, Bjorn Helgaas wrote: Hi Andrey, If you have a chance, can you try the attached two patches? The smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk patch makes the nw8000/nc8000 work, too. I've heard rumors that Windows does basically the same thing as the smsc-quirk patch, so I think there's a chance it might make your Toshiba work as well. I sent the smsc-preconfig patch to Andrew this morning. I'm going to do some more testing other HP laptops before sending him the smsc-quirk patch. Does not work, sorry. (Patches were taken from your another mails but I assume they are the same). Does not work even if I unload PCMCIA/yenta_socket to free resources. I am out of ideas but am ready to test patches if someone has. signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 15 June 2007 07:44:41 am Andrey Borzenkov wrote: On Friday 15 June 2007, Bjorn Helgaas wrote: Hi Andrey, If you have a chance, can you try the attached two patches? The smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk patch makes the nw8000/nc8000 work, too. I've heard rumors that Windows does basically the same thing as the smsc-quirk patch, so I think there's a chance it might make your Toshiba work as well. I sent the smsc-preconfig patch to Andrew this morning. I'm going to do some more testing other HP laptops before sending him the smsc-quirk patch. Does not work, sorry. (Patches were taken from your another mails but I assume they are the same). Does not work even if I unload PCMCIA/yenta_socket to free resources. I am out of ideas but am ready to test patches if someone has. Thanks for testing that. I bought a Portege 4000 so I can work on this without bothering you. I'll let you know if I make any progress on it. Bjorn - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Andrey,
If you have a chance, can you try the attached two patches? The
smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk
patch makes the nw8000/nc8000 work, too.
I've heard rumors that Windows does basically the same thing as the
smsc-quirk patch, so I think there's a chance it might make your
Toshiba work as well.
I sent the smsc-preconfig patch to Andrew this morning. I'm going
to do some more testing other HP laptops before sending him the
smsc-quirk patch.
Bjorn
[patch] smsc-ircc2: skip preconfiguration for PNP devices
If we rely on the device resources from PNPBIOS, we also have to
rely on the BIOS to configure any bridges on the way to the device.
Using the PNPBIOS resources but changing the configuration of a
bridge behind the back of the firmware is likely to make things
inconsistent.
This patch addresses part of this regression:
"no irda0 interface (2.6.21 was OK), smsc does not find chip"
It fixes smsc-ircc2 PNP device detection on HP nx5000 laptops.
Other laptops, including HP nc6000, HP nc8000, HP nw8000, and Toshiba
Portege 4000, still need PNP quirks to make this work.
With "smsc-ircc2.nopnp", we do the legacy device probe, including
manual bridge preconfiguration, as before.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c 2007-06-06 15:45:14.0 -0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-06 15:50:40.0 -0600
@@ -416,6 +416,13 @@
{
int ret = 0;
+#ifdef CONFIG_PCI
+ if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir, ircc_dma, ircc_irq) < 0) {
+ /* Ignore errors from preconfiguration */
+ IRDA_ERROR("%s, Preconfiguration failed !\n", driver_name);
+ }
+#endif
+
if (ircc_fir > 0 && ircc_sir > 0) {
IRDA_MESSAGE(" Overriding FIR address 0x%04x\n", ircc_fir);
IRDA_MESSAGE(" Overriding SIR address 0x%04x\n", ircc_sir);
@@ -459,13 +466,6 @@
return ret;
}
-#ifdef CONFIG_PCI
- if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir, ircc_dma, ircc_irq) < 0) {
- /* Ignore errors from preconfiguration */
- IRDA_ERROR("%s, Preconfiguration failed !\n", driver_name);
- }
-#endif
-
dev_count = 0;
if (smsc_nopnp || !pnp_platform_devices ||
[patch] PNP SMCf010 quirk: auto-config device if BIOS left it broken
Some HP firmware leaves the SMCf010 IRDA device incompletely configured,
or reports the wrong resources in _CRS. As a workaround, when we find
such a device, try to auto-configure the device.
This ignores the _CRS data, picks a config from _PRS, and runs _SRS to
configure the device. This makes smsc-ircc2 work correctly with PNP
resources on HP nx5000 and nc8000/nw8000 system.
I think Windows does something like this by default for all devices,
so we might want to consider doing the same thing in Linux.
Signed-off-by: Bjorn Helgaas <[EMAIL PROTECTED]>
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-14 15:08:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-14 15:09:56.0 -0600
@@ -107,31 +107,61 @@
return;
}
-static void quirk_smc_enable(struct pnp_dev *dev)
+static int quirk_smc_fir_enabled(struct pnp_dev *dev)
{
- unsigned int firbase;
+ unsigned long firbase;
+ u8 bank, high, low, chip;
+
+ if (!pnp_port_valid(dev, 1))
+ return 0;
+
+ firbase = pnp_port_start(dev, 1);
- if (!dev->active || !pnp_port_valid(dev, 1))
+ /* Select register bank 3 */
+ bank = inb(firbase + 7);
+ bank &= 0xf0;
+ bank |= 3;
+ outb(bank, firbase + 7);
+
+ high = inb(firbase + 0);
+ low = inb(firbase + 1);
+ chip = inb(firbase + 2);
+
+ /* This corresponds to the check in smsc_ircc_present() */
+ if (high == 0x10 && low == 0xb8 && (chip == 0xf1 || chip == 0xf2))
+ return 1;
+
+ return 0;
+}
+
+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))
return;
/*
- * On the HP/Compaq nw8240 (and probably other similar machines),
- * there is an SMCF010 device with two I/O port regions:
- *
- * 0x3e8-0x3ef SIR
- * 0x100-0x10f FIR
+ * Sometimes the BIOS claims the device is enabled, but it reports
+ * the wrong FIR resources or doesn't properly configure ISA or LPC
+ * bridges on the way to the device.
*
- * _STA reports the device is enabled, but in fact, the BIOS
- * neglects to enable the FIR range. Fortunately, it does fully
- * enable the device if we call _SRS.
+ * HP nc6000 and nc8000/nw8000 laptops have known problems like
+ * this. Fortunately, they do fix things up if we auto-configure
+ * the device using its _PRS and _SRS methods.
*/
- firbase = pnp_port_start(dev, 1);
- if (inb(firbase + 0x7 /* IRCC_MASTER */) == 0xff) {
- pnp_err("%s (%s) enabled
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Andrey,
If you have a chance, can you try the attached two patches? The
smsc-preconfig patch makes the HP nx5000 work, and the smsc-quirk
patch makes the nw8000/nc8000 work, too.
I've heard rumors that Windows does basically the same thing as the
smsc-quirk patch, so I think there's a chance it might make your
Toshiba work as well.
I sent the smsc-preconfig patch to Andrew this morning. I'm going
to do some more testing other HP laptops before sending him the
smsc-quirk patch.
Bjorn
[patch] smsc-ircc2: skip preconfiguration for PNP devices
If we rely on the device resources from PNPBIOS, we also have to
rely on the BIOS to configure any bridges on the way to the device.
Using the PNPBIOS resources but changing the configuration of a
bridge behind the back of the firmware is likely to make things
inconsistent.
This patch addresses part of this regression:
no irda0 interface (2.6.21 was OK), smsc does not find chip
It fixes smsc-ircc2 PNP device detection on HP nx5000 laptops.
Other laptops, including HP nc6000, HP nc8000, HP nw8000, and Toshiba
Portege 4000, still need PNP quirks to make this work.
With smsc-ircc2.nopnp, we do the legacy device probe, including
manual bridge preconfiguration, as before.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c 2007-06-06 15:45:14.0 -0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-06 15:50:40.0 -0600
@@ -416,6 +416,13 @@
{
int ret = 0;
+#ifdef CONFIG_PCI
+ if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir, ircc_dma, ircc_irq) 0) {
+ /* Ignore errors from preconfiguration */
+ IRDA_ERROR(%s, Preconfiguration failed !\n, driver_name);
+ }
+#endif
+
if (ircc_fir 0 ircc_sir 0) {
IRDA_MESSAGE( Overriding FIR address 0x%04x\n, ircc_fir);
IRDA_MESSAGE( Overriding SIR address 0x%04x\n, ircc_sir);
@@ -459,13 +466,6 @@
return ret;
}
-#ifdef CONFIG_PCI
- if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir, ircc_dma, ircc_irq) 0) {
- /* Ignore errors from preconfiguration */
- IRDA_ERROR(%s, Preconfiguration failed !\n, driver_name);
- }
-#endif
-
dev_count = 0;
if (smsc_nopnp || !pnp_platform_devices ||
[patch] PNP SMCf010 quirk: auto-config device if BIOS left it broken
Some HP firmware leaves the SMCf010 IRDA device incompletely configured,
or reports the wrong resources in _CRS. As a workaround, when we find
such a device, try to auto-configure the device.
This ignores the _CRS data, picks a config from _PRS, and runs _SRS to
configure the device. This makes smsc-ircc2 work correctly with PNP
resources on HP nx5000 and nc8000/nw8000 system.
I think Windows does something like this by default for all devices,
so we might want to consider doing the same thing in Linux.
Signed-off-by: Bjorn Helgaas [EMAIL PROTECTED]
Index: w/drivers/pnp/quirks.c
===
--- w.orig/drivers/pnp/quirks.c 2007-06-14 15:08:45.0 -0600
+++ w/drivers/pnp/quirks.c 2007-06-14 15:09:56.0 -0600
@@ -107,31 +107,61 @@
return;
}
-static void quirk_smc_enable(struct pnp_dev *dev)
+static int quirk_smc_fir_enabled(struct pnp_dev *dev)
{
- unsigned int firbase;
+ unsigned long firbase;
+ u8 bank, high, low, chip;
+
+ if (!pnp_port_valid(dev, 1))
+ return 0;
+
+ firbase = pnp_port_start(dev, 1);
- if (!dev-active || !pnp_port_valid(dev, 1))
+ /* Select register bank 3 */
+ bank = inb(firbase + 7);
+ bank = 0xf0;
+ bank |= 3;
+ outb(bank, firbase + 7);
+
+ high = inb(firbase + 0);
+ low = inb(firbase + 1);
+ chip = inb(firbase + 2);
+
+ /* This corresponds to the check in smsc_ircc_present() */
+ if (high == 0x10 low == 0xb8 (chip == 0xf1 || chip == 0xf2))
+ return 1;
+
+ return 0;
+}
+
+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))
return;
/*
- * On the HP/Compaq nw8240 (and probably other similar machines),
- * there is an SMCF010 device with two I/O port regions:
- *
- * 0x3e8-0x3ef SIR
- * 0x100-0x10f FIR
+ * Sometimes the BIOS claims the device is enabled, but it reports
+ * the wrong FIR resources or doesn't properly configure ISA or LPC
+ * bridges on the way to the device.
*
- * _STA reports the device is enabled, but in fact, the BIOS
- * neglects to enable the FIR range. Fortunately, it does fully
- * enable the device if we call _SRS.
+ * HP nc6000 and nc8000/nw8000 laptops have known problems like
+ * this. Fortunately, they do fix things up if we auto-configure
+ * the device using its _PRS and _SRS methods.
*/
- firbase = pnp_port_start(dev, 1);
- if (inb(firbase + 0x7 /* IRCC_MASTER */) == 0xff) {
- pnp_err(%s (%s) enabled but not responding, disabling
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 11 June 2007, Bjorn Helgaas wrote:
> > {pts/1}% lspnp -vv 00:0a
> > 00:0a SMCf010 SMC Fast Infrared Port
> > state = active
> > allocated resources:
> > io 0x100-0x107
> > ...
> >
> > {pts/1}% cat /proc/ioports
> > ...
> > 0100-013f : pcmcia_socket0
> > ...
> >
> > {pts/1}% sudo cat
> > /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io 0x0100
> > - 0x03af
> > 0x03e0 - 0x04ff
> > 0x0820 - 0x08ff
> > 0x0a00 - 0x0aff
> > 0x0c00 - 0x0cf7
>
> It's indeed very interesting that pcmcia_socket0 seems to have its
> fingers in the same ioport range the IR device thinks it's using.
> I don't know much about PCMCIA, but I can see I'm going to have to
> learn something :-)
>
For the record - I tried to completely unload PCMCIA driver for slot 0 (and
verified that 0x100 IO port is free) and tried to load smsc, but it did not
change anything whether I used first or second port for FIR.
> Can you send me your "lspci -vv" output, the whole /proc/ioports and
> /proc/iomem, and your dmesg log? And maybe your pcmcia_socket
> available_resources_io and available_resources_mem for good measure.
>
Sure.
lspci:
00:00.0 Host bridge: ALi Corporation M1644/M1644T Northbridge+Trident (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR-
Capabilities: [a4] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- SERR- TAbort-
Reset- FastB2B-
00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if
10 [OHCI])
Subsystem: Toshiba America Info Systems Unknown device 0004
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR- TAbort-
SERR+ TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- TAbort-
SERR- Reset+ 16bInt- PostWrite+
16-bit legacy interface ports at 0001
00:11.0 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus
Bridge with ZV Support (rev 32)
Subsystem: Toshiba America Info Systems Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00:11.1 CardBus bridge: Toshiba America Info Systems ToPIC100 PCI to Cardbus
Bridge with ZV Support (rev 32)
Subsystem: Toshiba America Info Systems Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- SERR- Reset- 16bInt+ PostWrite+
16-bit legacy interface ports at 0001
00:12.0 System peripheral: Toshiba America Info Systems SD TypA Controller
(rev 03)
Subsystem: Toshiba America Info Systems Unknown device 0001
Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
SERR- TAbort-
SERR-
Capabilities: [90] Power Management version 2
Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
/proc/ioports:
-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0100-013f : pcmcia_socket0
0170-0177 : :00:04.0
0170-0177 : libata
01f0-01f7 : :00:04.0
01f0-01f7 : libata
0376-0376 : :00:04.0
0376-0376 : libata
03c0-03df : vesafb
03f6-03f6 : :00:04.0
03f6-03f6 : libata
03f8-03ff : serial
0cf8-0cff : PCI conf1
1000-10ff : PCI CardBus #02
1400-14ff : PCI CardBus #02
1800-18ff : PCI CardBus #06
1c00-1cff : PCI CardBus #06
2000-20ff : PCI CardBus #0a
2400-24ff : PCI CardBus #0a
eb40-eb7f : :00:0a.0
eb40-eb7f : e100
ed00-edff : :00:06.0
ed00-edff : ALI 5451
ee00-ee3f : :00:08.0
ee00-ee03 : ACPI PM1a_EVT_BLK
ee04-ee05 : ACPI PM1a_CNT_BLK
ee08-ee0b : ACPI PM_TMR
ee10-ee15 : ACPI CPU throttle
ee18-ee27 : ACPI GPE0_BLK
ee34-ee34 : ACPI PM2_CNT_BLK
ef00-ef1f : :00:08.0
ef00-ef1f : ali1535_smbus
eff0-efff : :00:04.0
eff0-efff : libata
/proc/iomem:
-0009fbff : System RAM
0009fc00-0009 : reserved
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 11 June 2007, Bjorn Helgaas wrote:
{pts/1}% lspnp -vv 00:0a
00:0a SMCf010 SMC Fast Infrared Port
state = active
allocated resources:
io 0x100-0x107
...
{pts/1}% cat /proc/ioports
...
0100-013f : pcmcia_socket0
...
{pts/1}% sudo cat
/sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io 0x0100
- 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
It's indeed very interesting that pcmcia_socket0 seems to have its
fingers in the same ioport range the IR device thinks it's using.
I don't know much about PCMCIA, but I can see I'm going to have to
learn something :-)
For the record - I tried to completely unload PCMCIA driver for slot 0 (and
verified that 0x100 IO port is free) and tried to load smsc, but it did not
change anything whether I used first or second port for FIR.
Can you send me your lspci -vv output, the whole /proc/ioports and
/proc/iomem, and your dmesg log? And maybe your pcmcia_socket
available_resources_io and available_resources_mem for good measure.
Sure.
lspci:
00:00.0 Host bridge: ALi Corporation M1644/M1644T Northbridge+Trident (rev 01)
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort-
MAbort+ SERR- PERR+
Latency: 0
Region 0: Memory at f000 (32-bit, prefetchable) [size=64M]
Capabilities: [b0] AGP version 2.0
Status: RQ=28 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans-
64bit- FW-
AGP3- Rate=x1,x2,x4
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW-
Rate=none
Capabilities: [a4] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:01.0 PCI bridge: ALi Corporation PCI to AGP Controller (prog-if 00 [Normal
decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort-
MAbort- SERR- PERR-
Latency: 0
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
Memory behind bridge: f7f0-fdff
Prefetchable memory behind bridge: 4800-480f
Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium TAbort-
TAbort-
MAbort+ SERR- PERR+
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B-
00:02.0 USB Controller: ALi Corporation USB 1.1 Controller (rev 03) (prog-if
10 [OHCI])
Subsystem: Toshiba America Info Systems Unknown device 0004
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort-
MAbort- SERR- PERR-
Latency: 64 (2ns max), Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 11
Region 0: Memory at f7eff000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:04.0 IDE interface: ALi Corporation M5229 IDE (rev c3) (prog-if f0)
Subsystem: Toshiba America Info Systems Unknown device 0004
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort-
MAbort- SERR- PERR-
Latency: 64 (500ns min, 1000ns max)
Interrupt: pin A routed to IRQ 255
Region 0: [virtual] Memory at 01f0 (32-bit, non-prefetchable)
[disabled]
[size=8]
Region 1: [virtual] Memory at 03f0 (type 3, non-prefetchable)
[disabled]
[size=1]
Region 2: [virtual] Memory at 0170 (32-bit, non-prefetchable)
[disabled]
[size=8]
Region 3: [virtual] Memory at 0370 (type 3, non-prefetchable)
[disabled]
[size=1]
Region 4: I/O ports at eff0 [size=16]
Capabilities: [60] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link
Controller Audio Device (rev 01)
Subsystem: Toshiba America Info Systems Unknown device 0001
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping-
SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort-
TAbort-
MAbort- SERR+ PERR+
Latency: 64 (500ns min, 6000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at ed00 [size=256]
Region 1: Memory at f7efe000 (32-bit,
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 10 June 2007 12:47:07 am Andrey Borzenkov wrote:
> > Maybe we should also run the legacy probe when the PnP one fails. I
> > don't know how the preconfiguration stuff will behave with the device
> > being PnP enabled, but with your patch Andrey will still need to
> > modprobe smsc-ircc with smsc_nopnp.
>
> One thing that makes me uneasy - ideally we have to do it *after* PnP probe
> fails. Currently we lie to PnP layer that we successfully probed for device
> while in effect we did not (at least, not where PnP told us to).
>
> > So, here is the patch I propose (I had to move smsc_ircc_legacy_probe()
> > a bit earlier in the code to avoid forward declaration, but it's
> > basically your patch plus a call to smsc_ircc_legacy_probe() from the
> > pnp_probe() routine):
This patch does the legacy probe if PNP says we have an SMCf010, but
we couldn't make it work. In that situation, I think we need a PNP
quirk or other kernel PNP fix. Ultimately, we should only use the
legacy probe if we don't have PNP at all.
But we're a long ways from that. First, we have to figure out how
to make PNP detection work at all, then make sure it works for all
the machines we know about.
> Yes this patch works:
>
> [58674.337465] pnp: Device 00:0a activated.
> [58674.337465] smsc_ircc_present(), addr 0x02e8 - no device found!
> [58674.337465] PnP probe failed
> [58674.340799] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC
> IrDA chip, pre-configuring device.
So while this patch works, I don't think it's the right long-term
direction.
> {pts/1}% lspnp -vv 00:0a
> 00:0a SMCf010 SMC Fast Infrared Port
> state = active
> allocated resources:
> io 0x100-0x107
> ...
> {pts/1}% cat /proc/ioports
> ...
> 0100-013f : pcmcia_socket0
> ...
> {pts/1}% sudo cat
> /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
> 0x0100 - 0x03af
> 0x03e0 - 0x04ff
> 0x0820 - 0x08ff
> 0x0a00 - 0x0aff
> 0x0c00 - 0x0cf7
It's indeed very interesting that pcmcia_socket0 seems to have its
fingers in the same ioport range the IR device thinks it's using.
I don't know much about PCMCIA, but I can see I'm going to have to
learn something :-)
Can you send me your "lspci -vv" output, the whole /proc/ioports and
/proc/iomem, and your dmesg log? And maybe your pcmcia_socket
available_resources_io and available_resources_mem for good measure.
Bjorn
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 10 June 2007 02:03:03 am Andrey Borzenkov wrote: > > Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded > > automatically, and try this (along with my previous patch to swap > > FIR and SIR): > > > > # dmesg -n 8 > > # echo 0x200 > /sys/module/acpi/parameters/debug_level > > # echo disable > /sys/bus/pnp/devices/00:0a/resources > > # echo activate > /sys/bus/pnp/devices/00:0a/resources > > # modprobe smsc-ircc2 > > > > If you try this, can you collect the whole dmesg log? > > well, dmesg (/var/log/messages) is around 35MB :) Even bz2 compressed it is > over 700KB. I put it here: > http://dump.ru:80/loadfile.php?filename=fir_acpi_debug.bz2=379192 > > This is from /var/log/messages. I do not have serial console and cannot > capture output directly; I can only hope nothing is lost at this rate. Wow, that is big :-) I guess smsc-ircc2 still didn't find the device, so you got something like this: smsc_ircc_present(), addr 0x02e8 - no device found! Right? I'm out of ideas, and I don't want to waste more of your time on this. I'm going to try to find a Portege 4000 to play with myself. That might take a few days, and I'm going to be out of the office from June 20-July 9, so I'm afraid it will be slow. But I *will* fix it! Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Thursday 07 June 2007, Bjorn Helgaas wrote: > On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote: > > I am beginning to doubt whether drier > > works on my system at all (i.e. before PnP change); have to find time to > > test. > > In 2.6.21, smsc-ircc2 at least found the device. So we definitely have > a problem because in 2.6.22-rc, we don't find the device. > > What laptop do you have? Maybe I can find one to play with. > > I think Windows always calls _SRS, even if it doesn't need to change > the current resource settings. Linux doesn't do that, and my HP nw8240 > firmware has a bug that leaves the IR device partly-enabled until _SRS > is called. Maybe yours has a similar bug. > > Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded > automatically, and try this (along with my previous patch to swap > FIR and SIR): > > # dmesg -n 8 > # echo 0x200 > /sys/module/acpi/parameters/debug_level > # echo disable > /sys/bus/pnp/devices/00:0a/resources > # echo activate > /sys/bus/pnp/devices/00:0a/resources > # modprobe smsc-ircc2 > > If you try this, can you collect the whole dmesg log? > well, dmesg (/var/log/messages) is around 35MB :) Even bz2 compressed it is over 700KB. I put it here: http://dump.ru:80/loadfile.php?filename=fir_acpi_debug.bz2=379192 This is from /var/log/messages. I do not have serial console and cannot capture output directly; I can only hope nothing is lost at this rate. > It's also possible that some other driver like i2c is messing with > the ISA/LPC bridge configuration and breaking the IR device config. > Your lspnp output doesn't show any other ISA devices down there, > but I know i2c likes to poke around and discover things that kinda, > sorta work, but the BIOS didn't expose. > > Bjorn signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 08 June 2007, Samuel Ortiz wrote:
> Hi Bjorn,
>
> On 6/7/2007, "Bjorn Helgaas" <[EMAIL PROTECTED]> wrote:
> >On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
> >> On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> >> > On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
> >> > > On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> >> > > > Something's wrong with this strategy. The BIOS is telling us that
> >> > > > an SMCf010 device is present, active, and responds at io ports
> >> > > > 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on
> >> > > > the other side of an ISA or LPC bridge should be immaterial to the
> >> > > > OS driver.
> >> > >
> >> > > I thought this as well.
> >> >
> >> > If this is really true, it also means we shouldn't twiddle with the
> >> > bridge. If the BIOS left us a working setup, the preconfiguration
> >> > is certainly going to change it to something incompatible with the
> >> > PNP info.
> >> >
> >> > What if we try the following patch, which keeps the FIR/SIR swap and
> >> > just removes the preconfiguration?
> >>
> >> I already tried different patch but with similar effect (switch off
> >> preconfiguration) - it does not work. I am beginning to doubt whether
> >> drier works on my system at all (i.e. before PnP change); have to find
> >> time to test.
> >
> >OK. My patch wasn't the right approach anyway. Attached is what I
> >think we should do instead -- do the preconfig if we're not using PNP.
>
> Thats sounds good, yes.
> Maybe we should also run the legacy probe when the PnP one fails. I
> don't know how the preconfiguration stuff will behave with the device
> being PnP enabled, but with your patch Andrey will still need to
> modprobe smsc-ircc with smsc_nopnp.
>
One thing that makes me uneasy - ideally we have to do it *after* PnP probe
fails. Currently we lie to PnP layer that we successfully probed for device
while in effect we did not (at least, not where PnP told us to).
> So, here is the patch I propose (I had to move smsc_ircc_legacy_probe()
> a bit earlier in the code to avoid forward declaration, but it's
> basically your patch plus a call to smsc_ircc_legacy_probe() from the
> pnp_probe() routine):
>
Yes this patch works:
[58674.337465] pnp: Device 00:0a activated.
[58674.337465] smsc_ircc_present(), addr 0x02e8 - no device found!
[58674.337465] PnP probe failed
[58674.340799] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC
IrDA chip, pre-configuring device.
[58674.340799] Activated ALi 1533 ISA bridge port 0x02e8.
[58674.340799] Activated ALi 1533 ISA bridge port 0x02f8.
[58674.340799] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e):
LPC47N227
[58674.340799] smsc_superio_flat(): IrDA not enabled
[58674.340799] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7,
mode: 0x02
[58674.340799] SMsC IrDA Controller found
[58674.340799] IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
[58674.340799] No transceiver found. Defaulting to Fast pin select
But I noticed something very strange.
{pts/1}% lspnp -vv 00:0a
00:0a SMCf010 SMC Fast Infrared Port
state = active
allocated resources:
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
possible resources:
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,6,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
but
{pts/1}% cat /proc/ioports
-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0100-013f : pcmcia_socket0
^^ hell, what's it?
and really
{pts/1}% sudo
cat /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
0x0100 - 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
Does it mean we did not inform PnP layer when PCMCIA is configured? Should we
do it? I Cc to PCMCIA maintainer as well :) Configuration I have
{pts/1}% pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) bound to driver "wlags49"
Socket 1:
no card
Socket 2:
no card
{pts/1}% pccardctl info
PRODID_1="TOSHIBA"
PRODID_2="Wireless LAN Card"
PRODID_3="Version 01.01"
PRODID_4=""
MANFID=0156,0002
FUNCID=6
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=,
FUNCID=255
PRODID_1=""
PRODID_2=""
PRODID_3=""
PRODID_4=""
MANFID=,
FUNCID=255
>
> diff
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Friday 08 June 2007, Samuel Ortiz wrote:
Hi Bjorn,
On 6/7/2007, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
Something's wrong with this strategy. The BIOS is telling us that
an SMCf010 device is present, active, and responds at io ports
0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on
the other side of an ISA or LPC bridge should be immaterial to the
OS driver.
I thought this as well.
If this is really true, it also means we shouldn't twiddle with the
bridge. If the BIOS left us a working setup, the preconfiguration
is certainly going to change it to something incompatible with the
PNP info.
What if we try the following patch, which keeps the FIR/SIR swap and
just removes the preconfiguration?
I already tried different patch but with similar effect (switch off
preconfiguration) - it does not work. I am beginning to doubt whether
drier works on my system at all (i.e. before PnP change); have to find
time to test.
OK. My patch wasn't the right approach anyway. Attached is what I
think we should do instead -- do the preconfig if we're not using PNP.
Thats sounds good, yes.
Maybe we should also run the legacy probe when the PnP one fails. I
don't know how the preconfiguration stuff will behave with the device
being PnP enabled, but with your patch Andrey will still need to
modprobe smsc-ircc with smsc_nopnp.
One thing that makes me uneasy - ideally we have to do it *after* PnP probe
fails. Currently we lie to PnP layer that we successfully probed for device
while in effect we did not (at least, not where PnP told us to).
So, here is the patch I propose (I had to move smsc_ircc_legacy_probe()
a bit earlier in the code to avoid forward declaration, but it's
basically your patch plus a call to smsc_ircc_legacy_probe() from the
pnp_probe() routine):
Yes this patch works:
[58674.337465] pnp: Device 00:0a activated.
[58674.337465] smsc_ircc_present(), addr 0x02e8 - no device found!
[58674.337465] PnP probe failed
[58674.340799] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC
IrDA chip, pre-configuring device.
[58674.340799] Activated ALi 1533 ISA bridge port 0x02e8.
[58674.340799] Activated ALi 1533 ISA bridge port 0x02f8.
[58674.340799] found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e):
LPC47N227
[58674.340799] smsc_superio_flat(): IrDA not enabled
[58674.340799] smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7,
mode: 0x02
[58674.340799] SMsC IrDA Controller found
[58674.340799] IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
[58674.340799] No transceiver found. Defaulting to Fast pin select
But I noticed something very strange.
{pts/1}% lspnp -vv 00:0a
00:0a SMCf010 SMC Fast Infrared Port
state = active
allocated resources:
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
possible resources:
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,6,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
but
{pts/1}% cat /proc/ioports
-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0100-013f : pcmcia_socket0
^^ hell, what's it?
and really
{pts/1}% sudo
cat /sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
0x0100 - 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
Does it mean we did not inform PnP layer when PCMCIA is configured? Should we
do it? I Cc to PCMCIA maintainer as well :) Configuration I have
{pts/1}% pccardctl status
Socket 0:
3.3V 16-bit PC Card
Subdevice 0 (function 0) bound to driver wlags49
Socket 1:
no card
Socket 2:
no card
{pts/1}% pccardctl info
PRODID_1=TOSHIBA
PRODID_2=Wireless LAN Card
PRODID_3=Version 01.01
PRODID_4=
MANFID=0156,0002
FUNCID=6
PRODID_1=
PRODID_2=
PRODID_3=
PRODID_4=
MANFID=,
FUNCID=255
PRODID_1=
PRODID_2=
PRODID_3=
PRODID_4=
MANFID=,
FUNCID=255
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..1d7ab3f 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Thursday 07 June 2007, Bjorn Helgaas wrote: On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote: I am beginning to doubt whether drier works on my system at all (i.e. before PnP change); have to find time to test. In 2.6.21, smsc-ircc2 at least found the device. So we definitely have a problem because in 2.6.22-rc, we don't find the device. What laptop do you have? Maybe I can find one to play with. I think Windows always calls _SRS, even if it doesn't need to change the current resource settings. Linux doesn't do that, and my HP nw8240 firmware has a bug that leaves the IR device partly-enabled until _SRS is called. Maybe yours has a similar bug. Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded automatically, and try this (along with my previous patch to swap FIR and SIR): # dmesg -n 8 # echo 0x200 /sys/module/acpi/parameters/debug_level # echo disable /sys/bus/pnp/devices/00:0a/resources # echo activate /sys/bus/pnp/devices/00:0a/resources # modprobe smsc-ircc2 If you try this, can you collect the whole dmesg log? well, dmesg (/var/log/messages) is around 35MB :) Even bz2 compressed it is over 700KB. I put it here: http://dump.ru:80/loadfile.php?filename=fir_acpi_debug.bz2id=379192 This is from /var/log/messages. I do not have serial console and cannot capture output directly; I can only hope nothing is lost at this rate. It's also possible that some other driver like i2c is messing with the ISA/LPC bridge configuration and breaking the IR device config. Your lspnp output doesn't show any other ISA devices down there, but I know i2c likes to poke around and discover things that kinda, sorta work, but the BIOS didn't expose. Bjorn signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 10 June 2007 02:03:03 am Andrey Borzenkov wrote: Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded automatically, and try this (along with my previous patch to swap FIR and SIR): # dmesg -n 8 # echo 0x200 /sys/module/acpi/parameters/debug_level # echo disable /sys/bus/pnp/devices/00:0a/resources # echo activate /sys/bus/pnp/devices/00:0a/resources # modprobe smsc-ircc2 If you try this, can you collect the whole dmesg log? well, dmesg (/var/log/messages) is around 35MB :) Even bz2 compressed it is over 700KB. I put it here: http://dump.ru:80/loadfile.php?filename=fir_acpi_debug.bz2id=379192 This is from /var/log/messages. I do not have serial console and cannot capture output directly; I can only hope nothing is lost at this rate. Wow, that is big :-) I guess smsc-ircc2 still didn't find the device, so you got something like this: smsc_ircc_present(), addr 0x02e8 - no device found! Right? I'm out of ideas, and I don't want to waste more of your time on this. I'm going to try to find a Portege 4000 to play with myself. That might take a few days, and I'm going to be out of the office from June 20-July 9, so I'm afraid it will be slow. But I *will* fix it! Bjorn - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 10 June 2007 12:47:07 am Andrey Borzenkov wrote:
Maybe we should also run the legacy probe when the PnP one fails. I
don't know how the preconfiguration stuff will behave with the device
being PnP enabled, but with your patch Andrey will still need to
modprobe smsc-ircc with smsc_nopnp.
One thing that makes me uneasy - ideally we have to do it *after* PnP probe
fails. Currently we lie to PnP layer that we successfully probed for device
while in effect we did not (at least, not where PnP told us to).
So, here is the patch I propose (I had to move smsc_ircc_legacy_probe()
a bit earlier in the code to avoid forward declaration, but it's
basically your patch plus a call to smsc_ircc_legacy_probe() from the
pnp_probe() routine):
This patch does the legacy probe if PNP says we have an SMCf010, but
we couldn't make it work. In that situation, I think we need a PNP
quirk or other kernel PNP fix. Ultimately, we should only use the
legacy probe if we don't have PNP at all.
But we're a long ways from that. First, we have to figure out how
to make PNP detection work at all, then make sure it works for all
the machines we know about.
Yes this patch works:
[58674.337465] pnp: Device 00:0a activated.
[58674.337465] smsc_ircc_present(), addr 0x02e8 - no device found!
[58674.337465] PnP probe failed
[58674.340799] Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC
IrDA chip, pre-configuring device.
So while this patch works, I don't think it's the right long-term
direction.
{pts/1}% lspnp -vv 00:0a
00:0a SMCf010 SMC Fast Infrared Port
state = active
allocated resources:
io 0x100-0x107
...
{pts/1}% cat /proc/ioports
...
0100-013f : pcmcia_socket0
...
{pts/1}% sudo cat
/sys/class/pcmcia_socket/pcmcia_socket0/available_resources_io
0x0100 - 0x03af
0x03e0 - 0x04ff
0x0820 - 0x08ff
0x0a00 - 0x0aff
0x0c00 - 0x0cf7
It's indeed very interesting that pcmcia_socket0 seems to have its
fingers in the same ioport range the IR device thinks it's using.
I don't know much about PCMCIA, but I can see I'm going to have to
learn something :-)
Can you send me your lspci -vv output, the whole /proc/ioports and
/proc/iomem, and your dmesg log? And maybe your pcmcia_socket
available_resources_io and available_resources_mem for good measure.
Bjorn
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Thursday 07 June 2007, Bjorn Helgaas wrote: > In 2.6.21, smsc-ircc2 at least found the device. So we definitely have > a problem because in 2.6.22-rc, we don't find the device. > > What laptop do you have? Maybe I can find one to play with. > This is Toshiba Portege 4000. The rest of your questions later when I have time :) signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Bjorn,
On 6/7/2007, "Bjorn Helgaas" <[EMAIL PROTECTED]> wrote:
>On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
>> On Wednesday 06 June 2007, Bjorn Helgaas wrote:
>> > On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
>> > > On Wednesday 06 June 2007, Bjorn Helgaas wrote:
>> > > > Something's wrong with this strategy. The BIOS is telling us that an
>> > > > SMCf010 device is present, active, and responds at io ports 0x100-0x107
>> > > > and 0x2e8-0x2ef. The fact that it happens to be on the other side of
>> > > > an ISA or LPC bridge should be immaterial to the OS driver.
>> > >
>> > > I thought this as well.
>> >
>> > If this is really true, it also means we shouldn't twiddle with the
>> > bridge. If the BIOS left us a working setup, the preconfiguration
>> > is certainly going to change it to something incompatible with the
>> > PNP info.
>> >
>> > What if we try the following patch, which keeps the FIR/SIR swap and
>> > just removes the preconfiguration?
>>
>> I already tried different patch but with similar effect (switch off
>> preconfiguration) - it does not work. I am beginning to doubt whether drier
>> works on my system at all (i.e. before PnP change); have to find time to
>> test.
>
>OK. My patch wasn't the right approach anyway. Attached is what I
>think we should do instead -- do the preconfig if we're not using PNP.
Thats sounds good, yes.
Maybe we should also run the legacy probe when the PnP one fails. I
don't know how the preconfiguration stuff will behave with the device
being PnP enabled, but with your patch Andrey will still need to
modprobe smsc-ircc with smsc_nopnp.
So, here is the patch I propose (I had to move smsc_ircc_legacy_probe()
a bit earlier in the code to avoid forward declaration, but it's
basically your patch plus a call to smsc_ircc_legacy_probe() from the
pnp_probe() routine):
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..1d7ab3f 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -366,6 +366,44 @@ static inline void register_bank(int iobase, int bank)
iobase + IRCC_MASTER);
}
+
+static int __init smsc_ircc_legacy_probe(void)
+{
+ int ret = 0;
+
+#ifdef CONFIG_PCI
+ if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir,
+ ircc_dma, ircc_irq) < 0) {
+ /* Ignore errors from preconfiguration */
+ IRDA_ERROR("%s, Preconfiguration failed !\n", driver_name);
+ }
+#endif
+
+ if (ircc_fir > 0 && ircc_sir > 0) {
+ IRDA_MESSAGE(" Overriding FIR address 0x%04x\n", ircc_fir);
+ IRDA_MESSAGE(" Overriding SIR address 0x%04x\n", ircc_sir);
+
+ if (smsc_ircc_open(ircc_fir, ircc_sir, ircc_dma, ircc_irq))
+ ret = -ENODEV;
+ } else {
+ ret = -ENODEV;
+
+ /* try user provided configuration register base address */
+ if (ircc_cfg > 0) {
+ IRDA_MESSAGE(" Overriding configuration address "
+"0x%04x\n", ircc_cfg);
+ if (!smsc_superio_fdc(ircc_cfg))
+ ret = 0;
+ if (!smsc_superio_lpc(ircc_cfg))
+ ret = 0;
+ }
+
+ if (smsc_ircc_look_for_chips() > 0)
+ ret = 0;
+ }
+ return ret;
+}
+
/* PNP hotplug support */
static const struct pnp_device_id smsc_ircc_pnp_table[] = {
{ .id = "SMCf010", .driver_data = 0 },
@@ -391,9 +429,14 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev *dev,
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
- if (smsc_ircc_open(firbase, sirbase, dma, irq))
- return -ENODEV;
-
+ if (smsc_ircc_open(firbase, sirbase, dma, irq)) {
+ IRDA_ERROR("PnP probe failed\n");
+ if (smsc_ircc_legacy_probe()) {
+ IRDA_ERROR("Legacy probe failed\n");
+ return -ENODEV;
+ }
+ }
+
return 0;
}
@@ -412,35 +455,6 @@ static struct pnp_driver smsc_ircc_pnp_driver = {
*
***/
-static int __init smsc_ircc_legacy_probe(void)
-{
- int ret = 0;
-
- if (ircc_fir > 0 && ircc_sir > 0) {
- IRDA_MESSAGE(" Overriding FIR address 0x%04x\n", ircc_fir);
- IRDA_MESSAGE(" Overriding SIR address 0x%04x\n", ircc_sir);
-
- if (smsc_ircc_open(ircc_fir, ircc_sir, ircc_dma, ircc_irq))
- ret = -ENODEV;
- } else {
- ret = -ENODEV;
-
- /* try user provided configuration register base address */
- if (ircc_cfg > 0) {
- IRDA_MESSAGE(" Overriding configuration address "
-
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote: > I am beginning to doubt whether drier > works on my system at all (i.e. before PnP change); have to find time to > test. In 2.6.21, smsc-ircc2 at least found the device. So we definitely have a problem because in 2.6.22-rc, we don't find the device. What laptop do you have? Maybe I can find one to play with. I think Windows always calls _SRS, even if it doesn't need to change the current resource settings. Linux doesn't do that, and my HP nw8240 firmware has a bug that leaves the IR device partly-enabled until _SRS is called. Maybe yours has a similar bug. Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded automatically, and try this (along with my previous patch to swap FIR and SIR): # dmesg -n 8 # echo 0x200 > /sys/module/acpi/parameters/debug_level # echo disable > /sys/bus/pnp/devices/00:0a/resources # echo activate > /sys/bus/pnp/devices/00:0a/resources # modprobe smsc-ircc2 If you try this, can you collect the whole dmesg log? It's also possible that some other driver like i2c is messing with the ISA/LPC bridge configuration and breaking the IR device config. Your lspnp output doesn't show any other ISA devices down there, but I know i2c likes to poke around and discover things that kinda, sorta work, but the BIOS didn't expose. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
> On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> > On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
> > > On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> > > > Something's wrong with this strategy. The BIOS is telling us that an
> > > > SMCf010 device is present, active, and responds at io ports 0x100-0x107
> > > > and 0x2e8-0x2ef. The fact that it happens to be on the other side of
> > > > an ISA or LPC bridge should be immaterial to the OS driver.
> > >
> > > I thought this as well.
> >
> > If this is really true, it also means we shouldn't twiddle with the
> > bridge. If the BIOS left us a working setup, the preconfiguration
> > is certainly going to change it to something incompatible with the
> > PNP info.
> >
> > What if we try the following patch, which keeps the FIR/SIR swap and
> > just removes the preconfiguration?
>
> I already tried different patch but with similar effect (switch off
> preconfiguration) - it does not work. I am beginning to doubt whether drier
> works on my system at all (i.e. before PnP change); have to find time to
> test.
OK. My patch wasn't the right approach anyway. Attached is what I
think we should do instead -- do the preconfig if we're not using PNP.
I need to figure out how to test this though. The current smsc-ircc2
works on my HP nw8240, but I don't have any indication that it works
on laptops that require preconfiguration.
[patch] smsc-ircc2: skip preconfiguration for PNP devices
If we rely on the device resources from PNPBIOS, we also have to rely on
the BIOS to configure any bridges on the way to the device.
Using the PNPBIOS resources but twiddling the configuration of a
bridge behind the back of the firmware is likely to make things
inconsistent.
With "smsc-ircc2.nopnp", we do the legacy device probe, including
manual bridge preconfiguration, as before.
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-06 15:45:14.0
-0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-06 15:50:40.0 -0600
@@ -416,6 +416,13 @@
{
int ret = 0;
+#ifdef CONFIG_PCI
+ if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir,
ircc_dma, ircc_irq) < 0) {
+ /* Ignore errors from preconfiguration */
+ IRDA_ERROR("%s, Preconfiguration failed !\n", driver_name);
+ }
+#endif
+
if (ircc_fir > 0 && ircc_sir > 0) {
IRDA_MESSAGE(" Overriding FIR address 0x%04x\n", ircc_fir);
IRDA_MESSAGE(" Overriding SIR address 0x%04x\n", ircc_sir);
@@ -459,13 +466,6 @@
return ret;
}
-#ifdef CONFIG_PCI
- if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir,
ircc_dma, ircc_irq) < 0) {
- /* Ignore errors from preconfiguration */
- IRDA_ERROR("%s, Preconfiguration failed !\n", driver_name);
- }
-#endif
-
dev_count = 0;
if (smsc_nopnp || !pnp_platform_devices ||
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Thursday 07 June 2007 06:23:58 am Linus Walleij (LD/EAB) wrote: > Björn wrote: > > Something's wrong with this strategy. The BIOS is telling us > > that an SMCf010 device is present, active, and responds at io > > ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens > > to be on the other side of an ISA or LPC bridge should be > > immaterial to the OS driver. > > Yes, ideally. Yes of course it is wrong, or from a platonic > perspective. If nobody wrote buggy BIOS:es there would be no > problem. Yup, I agree that we will always need to work around BIOS bugs. But smsc-ircc2 contains a *lot* of preconfigure stuff. I'm skeptical that all of it is really to work around BIOS bugs. I think it's more likely that Linux just isn't using the PNP info correctly or drivers for other southbridge devices are getting in the way. > There is some history in the preconfigure functions: > these come from the smcinit tool (see http://irda.sourceforge.net/smcinit/), Thanks for the pointer. I'll read over that and see if I can find a laptop to play with. Bjorn - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Björn wrote: > Something's wrong with this strategy. The BIOS is telling us > that an SMCf010 device is present, active, and responds at io > ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens > to be on the other side of an ISA or LPC bridge should be > immaterial to the OS driver. Yes, ideally. Yes of course it is wrong, or from a platonic perspective. If nobody wrote buggy BIOS:es there would be no problem. There is some history in the preconfigure functions: these come from the smcinit tool (see http://irda.sourceforge.net/smcinit/), the hacks target laptops where the (buggy) BIOS does not properly preconfigure the bridge. The assumption in the current code is that Toshiba laptops with this smscchip will have the problem, because they always had in the past... I have no idea how bridges on such laptops are really preconfigured, possibly with some special hacks to the (manufacturer-supplied-assumed) "driver CD" for Windows only that apply some low-level tweaks to the WinNT/XP boot process. All info an reverse-engineering on this subject is warmly welcomed. There are some troubles further related to issues due to laptops supporting both ACPI and APM too I think, never dug into it. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Thursday 07 June 2007, Bjorn Helgaas wrote: In 2.6.21, smsc-ircc2 at least found the device. So we definitely have a problem because in 2.6.22-rc, we don't find the device. What laptop do you have? Maybe I can find one to play with. This is Toshiba Portege 4000. The rest of your questions later when I have time :) signature.asc Description: This is a digitally signed message part.
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Björn wrote: Something's wrong with this strategy. The BIOS is telling us that an SMCf010 device is present, active, and responds at io ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on the other side of an ISA or LPC bridge should be immaterial to the OS driver. Yes, ideally. Yes of course it is wrong, or from a platonic perspective. If nobody wrote buggy BIOS:es there would be no problem. There is some history in the preconfigure functions: these come from the smcinit tool (see http://irda.sourceforge.net/smcinit/), the hacks target laptops where the (buggy) BIOS does not properly preconfigure the bridge. The assumption in the current code is that Toshiba laptops with this smscchip will have the problem, because they always had in the past... I have no idea how bridges on such laptops are really preconfigured, possibly with some special hacks to the (manufacturer-supplied-assumed) driver CD for Windows only that apply some low-level tweaks to the WinNT/XP boot process. All info an reverse-engineering on this subject is warmly welcomed. There are some troubles further related to issues due to laptops supporting both ACPI and APM too I think, never dug into it. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Thursday 07 June 2007 06:23:58 am Linus Walleij (LD/EAB) wrote: Björn wrote: Something's wrong with this strategy. The BIOS is telling us that an SMCf010 device is present, active, and responds at io ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on the other side of an ISA or LPC bridge should be immaterial to the OS driver. Yes, ideally. Yes of course it is wrong, or from a platonic perspective. If nobody wrote buggy BIOS:es there would be no problem. Yup, I agree that we will always need to work around BIOS bugs. But smsc-ircc2 contains a *lot* of preconfigure stuff. I'm skeptical that all of it is really to work around BIOS bugs. I think it's more likely that Linux just isn't using the PNP info correctly or drivers for other southbridge devices are getting in the way. There is some history in the preconfigure functions: these come from the smcinit tool (see http://irda.sourceforge.net/smcinit/), Thanks for the pointer. I'll read over that and see if I can find a laptop to play with. Bjorn - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
Something's wrong with this strategy. The BIOS is telling us that an
SMCf010 device is present, active, and responds at io ports 0x100-0x107
and 0x2e8-0x2ef. The fact that it happens to be on the other side of
an ISA or LPC bridge should be immaterial to the OS driver.
I thought this as well.
If this is really true, it also means we shouldn't twiddle with the
bridge. If the BIOS left us a working setup, the preconfiguration
is certainly going to change it to something incompatible with the
PNP info.
What if we try the following patch, which keeps the FIR/SIR swap and
just removes the preconfiguration?
I already tried different patch but with similar effect (switch off
preconfiguration) - it does not work. I am beginning to doubt whether drier
works on my system at all (i.e. before PnP change); have to find time to
test.
OK. My patch wasn't the right approach anyway. Attached is what I
think we should do instead -- do the preconfig if we're not using PNP.
I need to figure out how to test this though. The current smsc-ircc2
works on my HP nw8240, but I don't have any indication that it works
on laptops that require preconfiguration.
[patch] smsc-ircc2: skip preconfiguration for PNP devices
If we rely on the device resources from PNPBIOS, we also have to rely on
the BIOS to configure any bridges on the way to the device.
Using the PNPBIOS resources but twiddling the configuration of a
bridge behind the back of the firmware is likely to make things
inconsistent.
With smsc-ircc2.nopnp, we do the legacy device probe, including
manual bridge preconfiguration, as before.
Index: w/drivers/net/irda/smsc-ircc2.c
===
--- w.orig/drivers/net/irda/smsc-ircc2.c2007-06-06 15:45:14.0
-0600
+++ w/drivers/net/irda/smsc-ircc2.c 2007-06-06 15:50:40.0 -0600
@@ -416,6 +416,13 @@
{
int ret = 0;
+#ifdef CONFIG_PCI
+ if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir,
ircc_dma, ircc_irq) 0) {
+ /* Ignore errors from preconfiguration */
+ IRDA_ERROR(%s, Preconfiguration failed !\n, driver_name);
+ }
+#endif
+
if (ircc_fir 0 ircc_sir 0) {
IRDA_MESSAGE( Overriding FIR address 0x%04x\n, ircc_fir);
IRDA_MESSAGE( Overriding SIR address 0x%04x\n, ircc_sir);
@@ -459,13 +466,6 @@
return ret;
}
-#ifdef CONFIG_PCI
- if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir,
ircc_dma, ircc_irq) 0) {
- /* Ignore errors from preconfiguration */
- IRDA_ERROR(%s, Preconfiguration failed !\n, driver_name);
- }
-#endif
-
dev_count = 0;
if (smsc_nopnp || !pnp_platform_devices ||
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote: I am beginning to doubt whether drier works on my system at all (i.e. before PnP change); have to find time to test. In 2.6.21, smsc-ircc2 at least found the device. So we definitely have a problem because in 2.6.22-rc, we don't find the device. What laptop do you have? Maybe I can find one to play with. I think Windows always calls _SRS, even if it doesn't need to change the current resource settings. Linux doesn't do that, and my HP nw8240 firmware has a bug that leaves the IR device partly-enabled until _SRS is called. Maybe yours has a similar bug. Can you set CONFIG_ACPI_DEBUG=y, make it so smsc-ircc2 isn't loaded automatically, and try this (along with my previous patch to swap FIR and SIR): # dmesg -n 8 # echo 0x200 /sys/module/acpi/parameters/debug_level # echo disable /sys/bus/pnp/devices/00:0a/resources # echo activate /sys/bus/pnp/devices/00:0a/resources # modprobe smsc-ircc2 If you try this, can you collect the whole dmesg log? It's also possible that some other driver like i2c is messing with the ISA/LPC bridge configuration and breaking the IR device config. Your lspnp output doesn't show any other ISA devices down there, but I know i2c likes to poke around and discover things that kinda, sorta work, but the BIOS didn't expose. Bjorn - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Bjorn,
On 6/7/2007, Bjorn Helgaas [EMAIL PROTECTED] wrote:
On Wednesday 06 June 2007 02:45:01 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
Something's wrong with this strategy. The BIOS is telling us that an
SMCf010 device is present, active, and responds at io ports 0x100-0x107
and 0x2e8-0x2ef. The fact that it happens to be on the other side of
an ISA or LPC bridge should be immaterial to the OS driver.
I thought this as well.
If this is really true, it also means we shouldn't twiddle with the
bridge. If the BIOS left us a working setup, the preconfiguration
is certainly going to change it to something incompatible with the
PNP info.
What if we try the following patch, which keeps the FIR/SIR swap and
just removes the preconfiguration?
I already tried different patch but with similar effect (switch off
preconfiguration) - it does not work. I am beginning to doubt whether drier
works on my system at all (i.e. before PnP change); have to find time to
test.
OK. My patch wasn't the right approach anyway. Attached is what I
think we should do instead -- do the preconfig if we're not using PNP.
Thats sounds good, yes.
Maybe we should also run the legacy probe when the PnP one fails. I
don't know how the preconfiguration stuff will behave with the device
being PnP enabled, but with your patch Andrey will still need to
modprobe smsc-ircc with smsc_nopnp.
So, here is the patch I propose (I had to move smsc_ircc_legacy_probe()
a bit earlier in the code to avoid forward declaration, but it's
basically your patch plus a call to smsc_ircc_legacy_probe() from the
pnp_probe() routine):
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..1d7ab3f 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -366,6 +366,44 @@ static inline void register_bank(int iobase, int bank)
iobase + IRCC_MASTER);
}
+
+static int __init smsc_ircc_legacy_probe(void)
+{
+ int ret = 0;
+
+#ifdef CONFIG_PCI
+ if (smsc_ircc_preconfigure_subsystems(ircc_cfg, ircc_fir, ircc_sir,
+ ircc_dma, ircc_irq) 0) {
+ /* Ignore errors from preconfiguration */
+ IRDA_ERROR(%s, Preconfiguration failed !\n, driver_name);
+ }
+#endif
+
+ if (ircc_fir 0 ircc_sir 0) {
+ IRDA_MESSAGE( Overriding FIR address 0x%04x\n, ircc_fir);
+ IRDA_MESSAGE( Overriding SIR address 0x%04x\n, ircc_sir);
+
+ if (smsc_ircc_open(ircc_fir, ircc_sir, ircc_dma, ircc_irq))
+ ret = -ENODEV;
+ } else {
+ ret = -ENODEV;
+
+ /* try user provided configuration register base address */
+ if (ircc_cfg 0) {
+ IRDA_MESSAGE( Overriding configuration address
+0x%04x\n, ircc_cfg);
+ if (!smsc_superio_fdc(ircc_cfg))
+ ret = 0;
+ if (!smsc_superio_lpc(ircc_cfg))
+ ret = 0;
+ }
+
+ if (smsc_ircc_look_for_chips() 0)
+ ret = 0;
+ }
+ return ret;
+}
+
/* PNP hotplug support */
static const struct pnp_device_id smsc_ircc_pnp_table[] = {
{ .id = SMCf010, .driver_data = 0 },
@@ -391,9 +429,14 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev *dev,
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
- if (smsc_ircc_open(firbase, sirbase, dma, irq))
- return -ENODEV;
-
+ if (smsc_ircc_open(firbase, sirbase, dma, irq)) {
+ IRDA_ERROR(PnP probe failed\n);
+ if (smsc_ircc_legacy_probe()) {
+ IRDA_ERROR(Legacy probe failed\n);
+ return -ENODEV;
+ }
+ }
+
return 0;
}
@@ -412,35 +455,6 @@ static struct pnp_driver smsc_ircc_pnp_driver = {
*
***/
-static int __init smsc_ircc_legacy_probe(void)
-{
- int ret = 0;
-
- if (ircc_fir 0 ircc_sir 0) {
- IRDA_MESSAGE( Overriding FIR address 0x%04x\n, ircc_fir);
- IRDA_MESSAGE( Overriding SIR address 0x%04x\n, ircc_sir);
-
- if (smsc_ircc_open(ircc_fir, ircc_sir, ircc_dma, ircc_irq))
- ret = -ENODEV;
- } else {
- ret = -ENODEV;
-
- /* try user provided configuration register base address */
- if (ircc_cfg 0) {
- IRDA_MESSAGE( Overriding configuration address
-0x%04x\n, ircc_cfg);
- if (!smsc_superio_fdc(ircc_cfg))
-
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Wednesday 06 June 2007, Bjorn Helgaas wrote: > On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote: > > On Wednesday 06 June 2007, Bjorn Helgaas wrote: > > > Something's wrong with this strategy. The BIOS is telling us that an > > > SMCf010 device is present, active, and responds at io ports 0x100-0x107 > > > and 0x2e8-0x2ef. The fact that it happens to be on the other side of > > > an ISA or LPC bridge should be immaterial to the OS driver. > > > > I thought this as well. > > If this is really true, it also means we shouldn't twiddle with the > bridge. If the BIOS left us a working setup, the preconfiguration > is certainly going to change it to something incompatible with the > PNP info. > > What if we try the following patch, which keeps the FIR/SIR swap and > just removes the preconfiguration? > I already tried different patch but with similar effect (switch off preconfiguration) - it does not work. I am beginning to doubt whether drier works on my system at all (i.e. before PnP change); have to find time to test. -andrey signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
> On Wednesday 06 June 2007, Bjorn Helgaas wrote:
> > Something's wrong with this strategy. The BIOS is telling us that an
> > SMCf010 device is present, active, and responds at io ports 0x100-0x107
> > and 0x2e8-0x2ef. The fact that it happens to be on the other side of
> > an ISA or LPC bridge should be immaterial to the OS driver.
>
> I thought this as well.
If this is really true, it also means we shouldn't twiddle with the
bridge. If the BIOS left us a working setup, the preconfiguration
is certainly going to change it to something incompatible with the
PNP info.
What if we try the following patch, which keeps the FIR/SIR swap and
just removes the preconfiguration?
Index: linux-2.6/drivers/net/irda/smsc-ircc2.c
===
--- linux-2.6.orig/drivers/net/irda/smsc-ircc2.c2007-06-04
10:35:03.0 -0600
+++ linux-2.6/drivers/net/irda/smsc-ircc2.c 2007-06-06 13:05:31.0
-0600
@@ -232,9 +232,7 @@
#ifdef CONFIG_PCI
static int __init preconfigure_smsc_chip(struct
smsc_ircc_subsystem_configuration *conf);
static int __init preconfigure_through_82801(struct pci_dev *dev, struct
smsc_ircc_subsystem_configuration *conf);
-static void __init preconfigure_ali_port(struct pci_dev *dev,
unsigned short port);
-static int __init preconfigure_through_ali(struct pci_dev *dev, struct
smsc_ircc_subsystem_configuration *conf);
static int __init smsc_ircc_preconfigure_subsystems(unsigned short ircc_cfg,
unsigned short ircc_fir,
unsigned short ircc_sir,
@@ -386,8 +384,8 @@
pnp_dma_valid(dev, 0) && pnp_irq_valid(dev, 0)))
return -EINVAL;
- sirbase = pnp_port_start(dev, 0);
- firbase = pnp_port_start(dev, 1);
+ firbase = pnp_port_start(dev, 0);
+ sirbase = pnp_port_start(dev, 1);
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
@@ -2511,20 +2509,6 @@
.preconfigure = preconfigure_through_82801,
.name = "Toshiba laptop with Intel 8281DBM LPC bridge",
},
- {
- /* ALi M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] */
- .vendor = PCIID_VENDOR_ALI,
- .device = 0x1533,
- .subvendor = 0x1179,
- .subdevice = 0x, /* 0x is "any" */
- .sir_io = 0x02e8,
- .fir_io = 0x02f8,
- .fir_irq = 0x07,
- .fir_dma = 0x03,
- .cfg_base = 0x002e,
- .preconfigure = preconfigure_through_ali,
- .name = "Toshiba laptop with ALi ISA bridge",
- },
{ } // Terminator
};
@@ -2783,63 +2767,6 @@
return preconfigure_smsc_chip(conf);
}
-/*
- * Pre-configure a certain port on the ALi 1533 bridge.
- * This is based on reverse-engineering since ALi does not
- * provide any data sheet for the 1533 chip.
- */
-static void __init preconfigure_ali_port(struct pci_dev *dev,
-unsigned short port)
-{
- unsigned char reg;
- /* These bits obviously control the different ports */
- unsigned char mask;
- unsigned char tmpbyte;
-
- switch(port) {
- case 0x0130:
- case 0x0178:
- reg = 0xb0;
- mask = 0x80;
- break;
- case 0x03f8:
- reg = 0xb4;
- mask = 0x80;
- break;
- case 0x02f8:
- reg = 0xb4;
- mask = 0x30;
- break;
- case 0x02e8:
- reg = 0xb4;
- mask = 0x08;
- break;
- default:
- IRDA_ERROR("Failed to configure unsupported port on ALi 1533
bridge: 0x%04x\n", port);
- return;
- }
-
- pci_read_config_byte(dev, reg, );
- /* Turn on the right bits */
- tmpbyte |= mask;
- pci_write_config_byte(dev, reg, tmpbyte);
- IRDA_MESSAGE("Activated ALi 1533 ISA bridge port 0x%04x.\n", port);
- return;
-}
-
-static int __init preconfigure_through_ali(struct pci_dev *dev,
- struct
- smsc_ircc_subsystem_configuration
- *conf)
-{
- /* Configure the two ports on the ALi 1533 */
- preconfigure_ali_port(dev, conf->sir_io);
- preconfigure_ali_port(dev, conf->fir_io);
-
- /* Pre-configure chip */
- return preconfigure_smsc_chip(conf);
-}
-
static int __init smsc_ircc_preconfigure_subsystems(unsigned short ircc_cfg,
unsigned short ircc_fir,
unsigned short ircc_sir,
-
To unsubscribe from this list:
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote:
On Wednesday 06 June 2007, Bjorn Helgaas wrote:
Something's wrong with this strategy. The BIOS is telling us that an
SMCf010 device is present, active, and responds at io ports 0x100-0x107
and 0x2e8-0x2ef. The fact that it happens to be on the other side of
an ISA or LPC bridge should be immaterial to the OS driver.
I thought this as well.
If this is really true, it also means we shouldn't twiddle with the
bridge. If the BIOS left us a working setup, the preconfiguration
is certainly going to change it to something incompatible with the
PNP info.
What if we try the following patch, which keeps the FIR/SIR swap and
just removes the preconfiguration?
Index: linux-2.6/drivers/net/irda/smsc-ircc2.c
===
--- linux-2.6.orig/drivers/net/irda/smsc-ircc2.c2007-06-04
10:35:03.0 -0600
+++ linux-2.6/drivers/net/irda/smsc-ircc2.c 2007-06-06 13:05:31.0
-0600
@@ -232,9 +232,7 @@
#ifdef CONFIG_PCI
static int __init preconfigure_smsc_chip(struct
smsc_ircc_subsystem_configuration *conf);
static int __init preconfigure_through_82801(struct pci_dev *dev, struct
smsc_ircc_subsystem_configuration *conf);
-static void __init preconfigure_ali_port(struct pci_dev *dev,
unsigned short port);
-static int __init preconfigure_through_ali(struct pci_dev *dev, struct
smsc_ircc_subsystem_configuration *conf);
static int __init smsc_ircc_preconfigure_subsystems(unsigned short ircc_cfg,
unsigned short ircc_fir,
unsigned short ircc_sir,
@@ -386,8 +384,8 @@
pnp_dma_valid(dev, 0) pnp_irq_valid(dev, 0)))
return -EINVAL;
- sirbase = pnp_port_start(dev, 0);
- firbase = pnp_port_start(dev, 1);
+ firbase = pnp_port_start(dev, 0);
+ sirbase = pnp_port_start(dev, 1);
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
@@ -2511,20 +2509,6 @@
.preconfigure = preconfigure_through_82801,
.name = Toshiba laptop with Intel 8281DBM LPC bridge,
},
- {
- /* ALi M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+] */
- .vendor = PCIID_VENDOR_ALI,
- .device = 0x1533,
- .subvendor = 0x1179,
- .subdevice = 0x, /* 0x is any */
- .sir_io = 0x02e8,
- .fir_io = 0x02f8,
- .fir_irq = 0x07,
- .fir_dma = 0x03,
- .cfg_base = 0x002e,
- .preconfigure = preconfigure_through_ali,
- .name = Toshiba laptop with ALi ISA bridge,
- },
{ } // Terminator
};
@@ -2783,63 +2767,6 @@
return preconfigure_smsc_chip(conf);
}
-/*
- * Pre-configure a certain port on the ALi 1533 bridge.
- * This is based on reverse-engineering since ALi does not
- * provide any data sheet for the 1533 chip.
- */
-static void __init preconfigure_ali_port(struct pci_dev *dev,
-unsigned short port)
-{
- unsigned char reg;
- /* These bits obviously control the different ports */
- unsigned char mask;
- unsigned char tmpbyte;
-
- switch(port) {
- case 0x0130:
- case 0x0178:
- reg = 0xb0;
- mask = 0x80;
- break;
- case 0x03f8:
- reg = 0xb4;
- mask = 0x80;
- break;
- case 0x02f8:
- reg = 0xb4;
- mask = 0x30;
- break;
- case 0x02e8:
- reg = 0xb4;
- mask = 0x08;
- break;
- default:
- IRDA_ERROR(Failed to configure unsupported port on ALi 1533
bridge: 0x%04x\n, port);
- return;
- }
-
- pci_read_config_byte(dev, reg, tmpbyte);
- /* Turn on the right bits */
- tmpbyte |= mask;
- pci_write_config_byte(dev, reg, tmpbyte);
- IRDA_MESSAGE(Activated ALi 1533 ISA bridge port 0x%04x.\n, port);
- return;
-}
-
-static int __init preconfigure_through_ali(struct pci_dev *dev,
- struct
- smsc_ircc_subsystem_configuration
- *conf)
-{
- /* Configure the two ports on the ALi 1533 */
- preconfigure_ali_port(dev, conf-sir_io);
- preconfigure_ali_port(dev, conf-fir_io);
-
- /* Pre-configure chip */
- return preconfigure_smsc_chip(conf);
-}
-
static int __init smsc_ircc_preconfigure_subsystems(unsigned short ircc_cfg,
unsigned short ircc_fir,
unsigned short ircc_sir,
-
To unsubscribe from this list: send the line
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Wednesday 06 June 2007, Bjorn Helgaas wrote: On Tuesday 05 June 2007 09:29:11 pm Andrey Borzenkov wrote: On Wednesday 06 June 2007, Bjorn Helgaas wrote: Something's wrong with this strategy. The BIOS is telling us that an SMCf010 device is present, active, and responds at io ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on the other side of an ISA or LPC bridge should be immaterial to the OS driver. I thought this as well. If this is really true, it also means we shouldn't twiddle with the bridge. If the BIOS left us a working setup, the preconfiguration is certainly going to change it to something incompatible with the PNP info. What if we try the following patch, which keeps the FIR/SIR swap and just removes the preconfiguration? I already tried different patch but with similar effect (switch off preconfiguration) - it does not work. I am beginning to doubt whether drier works on my system at all (i.e. before PnP change); have to find time to test. -andrey signature.asc Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Tuesday 05 June 2007 05:57:30 am Linus Walleij (LD/EAB) wrote: > You don't need to alter the defaults for the Toshiba ALi, the > preconfigure will respect the settings from the commandline, > e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8. > > BUT this value just won't work: we don't know how to tell the ALi 1533 > to use any other ports than 0x130,0x178,0x03f8,0x02f8 or 0x02e8. Something's wrong with this strategy. The BIOS is telling us that an SMCf010 device is present, active, and responds at io ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on the other side of an ISA or LPC bridge should be immaterial to the OS driver. If an ACPI BIOS says the device is active, I don't think the OS should have to preconfigure anything to make it work. I don't know whether this is just a broken BIOS on this machine, or whether we don't know how to use it correctly yet. The fact that we *do* have to preconfigure so much stuff in smsc-ircc2.c makes me think that Linux is missing something important in the way we deal with ISA and LPC bridges. Andrey, can you collect your ACPI DSDT and "lspnp -vv" [1] output? Maybe there will be a clue there. [1] ftp://ftp.kernel.org/pub/linux/kernel/people/helgaas/pnputils-0.1.tar.bz2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On 6/5/2007, "Linus Walleij (LD/EAB)" <[EMAIL PROTECTED]>
wrote:
>Sam wrote:
>
>> Andrey, in addition to Bjorn's patch, could you also apply
>> this one and try again:
>>
>> diff --git a/drivers/net/irda/smsc-ircc2.c
>> b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644
>> --- a/drivers/net/irda/smsc-ircc2.c
>> +++ b/drivers/net/irda/smsc-ircc2.c
>> @@ -2463,7 +2463,7 @@ static struct
>> smsc_ircc_subsystem_configuration subsystem_
>> .subvendor = 0x1179,
>> .subdevice = 0x, /* 0x is "any" */
>> .sir_io = 0x02e8,
>> - .fir_io = 0x02f8,
>> + .fir_io = 0x100,
>
>You don't need to alter the defaults for the Toshiba ALi, the
>preconfigure will respect the settings from the commandline,
>e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8.
True, that's faster.
>BUT this value just won't work: we don't know how to tell the ALi 1533
>to use any other ports than 0x130,0x178,0x03f8,0x02f8 or 0x02e8.
Oh, that's right. I didn't look carefully enough at
preconfigure_ali_port()...
>The code in preconfigure_ali_port() is from the smscinit tool
>and I have no idea of how that was initially developed (reverse
>engineering likely). Since 0x0130 and 0x170 seem to be the same setting,
>0x100 could be equal to one of the others as well so I would
>try feeding some different ircc_fir=x settings and see what happens.
>From the PnP output that Andrey sent, it seems that 0x130 might work.
If not, I guess it's worth trying at 0x100 while assuming it's the same
register setting as 0x130 or 0x178, so basically applying this patch on
top of Bjorn's one:
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 31c6233..0657228 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -2742,6 +2742,7 @@ static void __init preconfigure_ali_port(struct
pci_dev *d
unsigned char tmpbyte;
switch(port) {
+ case 0x0100:
case 0x0130:
case 0x0178:
reg = 0xb0;
and then a modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8
Cheers,
Samuel.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Andrey wrote:
> And here is what PnP tells us:
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/options
> port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding irq
> 3,4,5,6,7,10,11 High-Edge dma 1,2,3 16-bit compatible
> Dependent: 01 - Priority acceptable
>port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 02 - Priority acceptable
>port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 03 - Priority acceptable
>port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 04 - Priority acceptable
>port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> state = disabled
> {pts/1}% sudo sh -c 'echo activate >
/sys/bus/pnp/devices/00:0a/resources'
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> state = active
> io 0x100-0x107
> io 0x2e8-0x2ef
> irq 5
> dma 1
These values *could* be correct (not all PnP BIOS:es can be trusted,
apparently). What we need to do really, is to get PnP working
properly with smsc-ircc2 and the pass these PnP settings through
as if they were parameters to the module, in the call to
smsc_ircc_preconfigure_subsystems() in the smsc_ircc_init() call.
Then it will (probably) preconfigure the bridge for the
correct ports all the time.
The static table I've put in there just happens to be factory
defaults on a few machines, subject to change whenever some HW
is added/removed I believe.
Linus
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Sam wrote: > Andrey, in addition to Bjorn's patch, could you also apply > this one and try again: > > diff --git a/drivers/net/irda/smsc-ircc2.c > b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644 > --- a/drivers/net/irda/smsc-ircc2.c > +++ b/drivers/net/irda/smsc-ircc2.c > @@ -2463,7 +2463,7 @@ static struct > smsc_ircc_subsystem_configuration subsystem_ > .subvendor = 0x1179, > .subdevice = 0x, /* 0x is "any" */ > .sir_io = 0x02e8, > - .fir_io = 0x02f8, > + .fir_io = 0x100, You don't need to alter the defaults for the Toshiba ALi, the preconfigure will respect the settings from the commandline, e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8. BUT this value just won't work: we don't know how to tell the ALi 1533 to use any other ports than 0x130,0x178,0x03f8,0x02f8 or 0x02e8. The code in preconfigure_ali_port() is from the smscinit tool and I have no idea of how that was initially developed (reverse engineering likely). Since 0x0130 and 0x170 seem to be the same setting, 0x100 could be equal to one of the others as well so I would try feeding some different ircc_fir=x settings and see what happens. The problem is we don't have any documentation for this bridge and even though I've requested a datasheet from ALi they refuse to provide one. I even tried buying one in the grey market and failed, if someone has it, please forward. Linus Walleij - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Linus, On 6/5/2007, "Linus Walleij (LD/EAB)" <[EMAIL PROTECTED]> wrote: >> > Ok, FIR and SIR are definitey mixed up. So, now could you please >try >> > Bjorn's patch ? >> >> does not work. > >It looks like the purpose of the patch is to provide more printouts >not to fix the problem, please mail your dmesg post-patch. Here it is (from an answer from Andrey to Bjorn, you were not included yet): Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. Activated ALi 1533 ISA bridge port 0x02e8. Activated ALi 1533 ISA bridge port 0x02f8. pnp: Device 00:0a activated. smsc_ircc_pnp_probe(): fir 0x100 sir 0x2e8 dma 1 irq 5 High: 0x11, Chip 0x0 smsc_ircc_present(), addr 0x0100 - no device found! pnp: Device 00:0a disabled. Andrey, in addition to Bjorn's patch, could you also apply this one and try again: diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644 --- a/drivers/net/irda/smsc-ircc2.c +++ b/drivers/net/irda/smsc-ircc2.c @@ -2463,7 +2463,7 @@ static struct smsc_ircc_subsystem_configuration subsystem_ .subvendor = 0x1179, .subdevice = 0x, /* 0x is "any" */ .sir_io = 0x02e8, - .fir_io = 0x02f8, + .fir_io = 0x100, .fir_irq = 0x07, .fir_dma = 0x03, .cfg_base = 0x002e, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
> > Ok, FIR and SIR are definitey mixed up. So, now could you please try > > Bjorn's patch ? > > does not work. It looks like the purpose of the patch is to provide more printouts not to fix the problem, please mail your dmesg post-patch. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Ok, FIR and SIR are definitey mixed up. So, now could you please try Bjorn's patch ? does not work. It looks like the purpose of the patch is to provide more printouts not to fix the problem, please mail your dmesg post-patch. Linus - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Linus, On 6/5/2007, Linus Walleij (LD/EAB) [EMAIL PROTECTED] wrote: Ok, FIR and SIR are definitey mixed up. So, now could you please try Bjorn's patch ? does not work. It looks like the purpose of the patch is to provide more printouts not to fix the problem, please mail your dmesg post-patch. Here it is (from an answer from Andrey to Bjorn, you were not included yet): Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip, pre-configuring device. Activated ALi 1533 ISA bridge port 0x02e8. Activated ALi 1533 ISA bridge port 0x02f8. pnp: Device 00:0a activated. smsc_ircc_pnp_probe(): fir 0x100 sir 0x2e8 dma 1 irq 5 High: 0x11, Chip 0x0 smsc_ircc_present(), addr 0x0100 - no device found! pnp: Device 00:0a disabled. Andrey, in addition to Bjorn's patch, could you also apply this one and try again: diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644 --- a/drivers/net/irda/smsc-ircc2.c +++ b/drivers/net/irda/smsc-ircc2.c @@ -2463,7 +2463,7 @@ static struct smsc_ircc_subsystem_configuration subsystem_ .subvendor = 0x1179, .subdevice = 0x, /* 0x is any */ .sir_io = 0x02e8, - .fir_io = 0x02f8, + .fir_io = 0x100, .fir_irq = 0x07, .fir_dma = 0x03, .cfg_base = 0x002e, - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Sam wrote: Andrey, in addition to Bjorn's patch, could you also apply this one and try again: diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644 --- a/drivers/net/irda/smsc-ircc2.c +++ b/drivers/net/irda/smsc-ircc2.c @@ -2463,7 +2463,7 @@ static struct smsc_ircc_subsystem_configuration subsystem_ .subvendor = 0x1179, .subdevice = 0x, /* 0x is any */ .sir_io = 0x02e8, - .fir_io = 0x02f8, + .fir_io = 0x100, You don't need to alter the defaults for the Toshiba ALi, the preconfigure will respect the settings from the commandline, e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8. BUT this value just won't work: we don't know how to tell the ALi 1533 to use any other ports than 0x130,0x178,0x03f8,0x02f8 or 0x02e8. The code in preconfigure_ali_port() is from the smscinit tool and I have no idea of how that was initially developed (reverse engineering likely). Since 0x0130 and 0x170 seem to be the same setting, 0x100 could be equal to one of the others as well so I would try feeding some different ircc_fir=x settings and see what happens. The problem is we don't have any documentation for this bridge and even though I've requested a datasheet from ALi they refuse to provide one. I even tried buying one in the grey market and failed, if someone has it, please forward. Linus Walleij - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Andrey wrote:
And here is what PnP tells us:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/options
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding irq
3,4,5,6,7,10,11 High-Edge dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = disabled
{pts/1}% sudo sh -c 'echo activate
/sys/bus/pnp/devices/00:0a/resources'
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
These values *could* be correct (not all PnP BIOS:es can be trusted,
apparently). What we need to do really, is to get PnP working
properly with smsc-ircc2 and the pass these PnP settings through
as if they were parameters to the module, in the call to
smsc_ircc_preconfigure_subsystems() in the smsc_ircc_init() call.
Then it will (probably) preconfigure the bridge for the
correct ports all the time.
The static table I've put in there just happens to be factory
defaults on a few machines, subject to change whenever some HW
is added/removed I believe.
Linus
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
RE: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On 6/5/2007, Linus Walleij (LD/EAB) [EMAIL PROTECTED]
wrote:
Sam wrote:
Andrey, in addition to Bjorn's patch, could you also apply
this one and try again:
diff --git a/drivers/net/irda/smsc-ircc2.c
b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -2463,7 +2463,7 @@ static struct
smsc_ircc_subsystem_configuration subsystem_
.subvendor = 0x1179,
.subdevice = 0x, /* 0x is any */
.sir_io = 0x02e8,
- .fir_io = 0x02f8,
+ .fir_io = 0x100,
You don't need to alter the defaults for the Toshiba ALi, the
preconfigure will respect the settings from the commandline,
e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8.
True, that's faster.
BUT this value just won't work: we don't know how to tell the ALi 1533
to use any other ports than 0x130,0x178,0x03f8,0x02f8 or 0x02e8.
Oh, that's right. I didn't look carefully enough at
preconfigure_ali_port()...
The code in preconfigure_ali_port() is from the smscinit tool
and I have no idea of how that was initially developed (reverse
engineering likely). Since 0x0130 and 0x170 seem to be the same setting,
0x100 could be equal to one of the others as well so I would
try feeding some different ircc_fir=x settings and see what happens.
From the PnP output that Andrey sent, it seems that 0x130 might work.
If not, I guess it's worth trying at 0x100 while assuming it's the same
register setting as 0x130 or 0x178, so basically applying this patch on
top of Bjorn's one:
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 31c6233..0657228 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -2742,6 +2742,7 @@ static void __init preconfigure_ali_port(struct
pci_dev *d
unsigned char tmpbyte;
switch(port) {
+ case 0x0100:
case 0x0130:
case 0x0178:
reg = 0xb0;
and then a modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8
Cheers,
Samuel.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Tuesday 05 June 2007 05:57:30 am Linus Walleij (LD/EAB) wrote: You don't need to alter the defaults for the Toshiba ALi, the preconfigure will respect the settings from the commandline, e.g. modprobe smsc-ircc2 ircc_fir=0x100,ircc_sir=0x02e8. BUT this value just won't work: we don't know how to tell the ALi 1533 to use any other ports than 0x130,0x178,0x03f8,0x02f8 or 0x02e8. Something's wrong with this strategy. The BIOS is telling us that an SMCf010 device is present, active, and responds at io ports 0x100-0x107 and 0x2e8-0x2ef. The fact that it happens to be on the other side of an ISA or LPC bridge should be immaterial to the OS driver. If an ACPI BIOS says the device is active, I don't think the OS should have to preconfigure anything to make it work. I don't know whether this is just a broken BIOS on this machine, or whether we don't know how to use it correctly yet. The fact that we *do* have to preconfigure so much stuff in smsc-ircc2.c makes me think that Linux is missing something important in the way we deal with ISA and LPC bridges. Andrey, can you collect your ACPI DSDT and lspnp -vv [1] output? Maybe there will be a clue there. [1] ftp://ftp.kernel.org/pub/linux/kernel/people/helgaas/pnputils-0.1.tar.bz2 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Tuesday 05 June 2007, Samuel Ortiz wrote:
> (Adding Linus Walleij, who wrote part of the smsc driver, to Cc:)
>
> On Mon, Jun 04, 2007 at 06:33:56AM +0400, Andrey Borzenkov wrote:
> > On Monday 04 June 2007, Samuel Ortiz wrote:
> > > It seems that PnP tells us that the FIR port is at 0x2e8 while we're
> > > expecting it at 0x2f8.
> > > Could you apply this patch and then send me a dmesg dump of the
> > > smsc-ircc initialisation ?
> >
> > here is dmesg:
> >
> > Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
> > pre-configuring device.
> > Activated ALi 1533 ISA bridge port 0x02e8.
> > Activated ALi 1533 ISA bridge port 0x02f8.
> > pnp: Device 00:0a activated.
> > smsc_ircc_pnp_probe(): fir 0x2e8 sir 0x100 dma 1 irq 5
>
> Ok, FIR and SIR are definitey mixed up. So, now could you please try
> Bjorn's patch ?
does not work.
> I wonder if the curent code (without PnP) enables 0x2f8 as
> the SIR port through the preconfiguration code...
>
> Cheers,
> Samuel.
>
> > High: 0xef, Chip 0x1
> > smsc_ircc_present(), addr 0x02e8 - no device found!
> > pnp: Device 00:0a disabled.
> >
> > And here is what PnP tells us:
> > {pts/1}% cat /sys/bus/pnp/devices/00:0a/options
> > port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
> > irq 3,4,5,6,7,10,11 High-Edge
> > dma 1,2,3 16-bit compatible
> > Dependent: 01 - Priority acceptable
> >port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
> > Dependent: 02 - Priority acceptable
> >port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
> > Dependent: 03 - Priority acceptable
> >port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
> > Dependent: 04 - Priority acceptable
> >port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
> > {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> > state = disabled
> > {pts/1}% sudo sh -c 'echo activate >
> > /sys/bus/pnp/devices/00:0a/resources' {pts/1}% cat
> > /sys/bus/pnp/devices/00:0a/resources
> > state = active
> > io 0x100-0x107
> > io 0x2e8-0x2ef
> > irq 5
> > dma 1
> >
> > -andrey
> >
> > > Cheers,
> > > Samuel.
> > >
> > >
> > > diff --git a/drivers/net/irda/smsc-ircc2.c
> > > b/drivers/net/irda/smsc-ircc2.c index 9043bf4..d1d46a6 100644
> > > --- a/drivers/net/irda/smsc-ircc2.c
> > > +++ b/drivers/net/irda/smsc-ircc2.c
> > > @@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct
> > > pnp_dev *dev, dma = pnp_dma(dev, 0);
> > > irq = pnp_irq(dev, 0);
> > >
> > > + printk("%s(): fir 0x%x sir 0x%x dma %d irq %d\n",
> > > +__FUNCTION__, firbase, sirbase, dma, irq);
> > > +
> > > if (smsc_ircc_open(firbase, sirbase, dma, irq))
> > > return -ENODEV;
> > >
> > > @@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
> > > unsigned int sir_base) irq = (config & IRCC_INTERFACE_IRQ_MASK) >>
> > > 4;
> > >
> > > if (high != 0x10 || low != 0xb8 || (chip != 0xf1 && chip != 0xf2)) {
> > > + printk("High: 0x%x, Chip 0x%x\n", high, chip);
> > > IRDA_WARNING("%s(), addr 0x%04x - no device found!\n",
> > >__FUNCTION__, fir_base);
> > > goto out3;
signature.asc
Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 04 June 2007, Bjorn Helgaas wrote:
> On Sunday 03 June 2007 02:16:05 am Andrey Borzenkov wrote:
> > On Sunday 03 June 2007, Andrey Borzenkov wrote:
> > > Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
> > > Nothing was changed in setup except kernel version.
> > >
> > > 2.6.21:
> > >
> > > Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA
> > > chip, pre-configuring device.
> > > Activated ALi 1533 ISA bridge port 0x02e8.
> > > Activated ALi 1533 ISA bridge port 0x02f8.
> > > found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> > > smsc_superio_flat(): IrDA not enabled
>
> The "IrDA not enabled" makes me think that even in the working case,
> the BIOS left the IR port disabled. Are there any BIOS setup switches
> that affect this port?
>
No (at least in BIOS setup screens). The closest is COM port setting
(IRQ/DMA). This looks funny as I do not have COM interface anyway but may be
docking station has.
> > > smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode:
> > > 0x02 SMsC IrDA Controller found
> > > IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
>
> It seems strange that both FIR and SIR would use legacy COM ports
> (0x2f8 == COM2, 0x2e8 == COM4). My HP nw8240 has SIR at 0x3e8 (COM3)
> and FIR at 0x100.
>
Well, this is how code was written. There was no autodetection anyway, it used
hardcoded builtin (unless overridden).
> Do you know if both the FIR and SIR interfaces work? I'm wondering if
> your irda0 only uses SIR at 0x2e8, and FIR has always been broken.
>
How can I check it?
> > > No transceiver found. Defaulting to Fast pin select
> > > IrDA: Registered device irda0
> > >
> > >
> > > 2.6.22-rc3:
> > > Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA
> > > chip, pre-configuring device.
> > > Activated ALi 1533 ISA bridge port 0x02e8.
> > > Activated ALi 1533 ISA bridge port 0x02f8.
> > > pnp: Device 00:0a activated.
> > > smsc_ircc_present(), addr 0x02e8 - no device found!
> > > pnp: Device 00:0a disabled.
> >
> > {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> > state = active
> > io 0x100-0x107
> > io 0x2e8-0x2ef
> > irq 5
> > dma 1
>
> The PNP probe I added expects SIR at the first range and FIR at the
> second. I would think the 0x2e8 range would be SIR, since it's compatible
> with a COM port. Is it possible the BIOS just reports these in the
> opposite order, with FIR first and SIR second? Can you try the patch
> below?
>
It does not work unfortunately:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_pnp_probe(): fir 0x100 sir 0x2e8 dma 1 irq 5
High: 0x11, Chip 0x0
smsc_ircc_present(), addr 0x0100 - no device found!
pnp: Device 00:0a disabled.
> Index: linux-2.6/drivers/net/irda/smsc-ircc2.c
> ===
> --- linux-2.6.orig/drivers/net/irda/smsc-ircc2.c 2007-06-04
> 10:21:46.0 -0600 +++
> linux-2.6/drivers/net/irda/smsc-ircc2.c 2007-06-04 10:21:57.0
> -0600
> @@ -386,8 +386,8 @@
> pnp_dma_valid(dev, 0) && pnp_irq_valid(dev, 0)))
> return -EINVAL;
>
> - sirbase = pnp_port_start(dev, 0);
> - firbase = pnp_port_start(dev, 1);
> + firbase = pnp_port_start(dev, 0);
> + sirbase = pnp_port_start(dev, 1);
> dma = pnp_dma(dev, 0);
> irq = pnp_irq(dev, 0);
signature.asc
Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
(Adding Linus Walleij, who wrote part of the smsc driver, to Cc:)
On Mon, Jun 04, 2007 at 06:33:56AM +0400, Andrey Borzenkov wrote:
> On Monday 04 June 2007, Samuel Ortiz wrote:
> > It seems that PnP tells us that the FIR port is at 0x2e8 while we're
> > expecting it at 0x2f8.
> > Could you apply this patch and then send me a dmesg dump of the
> > smsc-ircc initialisation ?
> >
>
> here is dmesg:
>
> Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
> pre-configuring device.
> Activated ALi 1533 ISA bridge port 0x02e8.
> Activated ALi 1533 ISA bridge port 0x02f8.
> pnp: Device 00:0a activated.
> smsc_ircc_pnp_probe(): fir 0x2e8 sir 0x100 dma 1 irq 5
Ok, FIR and SIR are definitey mixed up. So, now could you please try Bjorn's
patch ? I wonder if the curent code (without PnP) enables 0x2f8 as the SIR
port through the preconfiguration code...
Cheers,
Samuel.
> High: 0xef, Chip 0x1
> smsc_ircc_present(), addr 0x02e8 - no device found!
> pnp: Device 00:0a disabled.
>
> And here is what PnP tells us:
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/options
> port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
> irq 3,4,5,6,7,10,11 High-Edge
> dma 1,2,3 16-bit compatible
> Dependent: 01 - Priority acceptable
>port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 02 - Priority acceptable
>port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 03 - Priority acceptable
>port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
> Dependent: 04 - Priority acceptable
>port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> state = disabled
> {pts/1}% sudo sh -c 'echo activate > /sys/bus/pnp/devices/00:0a/resources'
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> state = active
> io 0x100-0x107
> io 0x2e8-0x2ef
> irq 5
> dma 1
>
> -andrey
>
> > Cheers,
> > Samuel.
> >
> >
> > diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
> > index 9043bf4..d1d46a6 100644
> > --- a/drivers/net/irda/smsc-ircc2.c
> > +++ b/drivers/net/irda/smsc-ircc2.c
> > @@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev
> > *dev, dma = pnp_dma(dev, 0);
> > irq = pnp_irq(dev, 0);
> >
> > + printk("%s(): fir 0x%x sir 0x%x dma %d irq %d\n",
> > + __FUNCTION__, firbase, sirbase, dma, irq);
> > +
> > if (smsc_ircc_open(firbase, sirbase, dma, irq))
> > return -ENODEV;
> >
> > @@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
> > unsigned int sir_base) irq = (config & IRCC_INTERFACE_IRQ_MASK) >> 4;
> >
> > if (high != 0x10 || low != 0xb8 || (chip != 0xf1 && chip != 0xf2)) {
> > + printk("High: 0x%x, Chip 0x%x\n", high, chip);
> > IRDA_WARNING("%s(), addr 0x%04x - no device found!\n",
> > __FUNCTION__, fir_base);
> > goto out3;
>
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 03 June 2007 02:16:05 am Andrey Borzenkov wrote:
> On Sunday 03 June 2007, Andrey Borzenkov wrote:
> > Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
> > Nothing was changed in setup except kernel version.
> >
> > 2.6.21:
> >
> > Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
> > pre-configuring device.
> > Activated ALi 1533 ISA bridge port 0x02e8.
> > Activated ALi 1533 ISA bridge port 0x02f8.
> > found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> > smsc_superio_flat(): IrDA not enabled
The "IrDA not enabled" makes me think that even in the working case,
the BIOS left the IR port disabled. Are there any BIOS setup switches
that affect this port?
> > smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
> > SMsC IrDA Controller found
> > IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
It seems strange that both FIR and SIR would use legacy COM ports
(0x2f8 == COM2, 0x2e8 == COM4). My HP nw8240 has SIR at 0x3e8 (COM3)
and FIR at 0x100.
Do you know if both the FIR and SIR interfaces work? I'm wondering if
your irda0 only uses SIR at 0x2e8, and FIR has always been broken.
> > No transceiver found. Defaulting to Fast pin select
> > IrDA: Registered device irda0
> >
> >
> > 2.6.22-rc3:
> > Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
> > pre-configuring device.
> > Activated ALi 1533 ISA bridge port 0x02e8.
> > Activated ALi 1533 ISA bridge port 0x02f8.
> > pnp: Device 00:0a activated.
> > smsc_ircc_present(), addr 0x02e8 - no device found!
> > pnp: Device 00:0a disabled.
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
> state = active
> io 0x100-0x107
> io 0x2e8-0x2ef
> irq 5
> dma 1
The PNP probe I added expects SIR at the first range and FIR at the
second. I would think the 0x2e8 range would be SIR, since it's compatible
with a COM port. Is it possible the BIOS just reports these in the
opposite order, with FIR first and SIR second? Can you try the patch
below?
Index: linux-2.6/drivers/net/irda/smsc-ircc2.c
===
--- linux-2.6.orig/drivers/net/irda/smsc-ircc2.c2007-06-04
10:21:46.0 -0600
+++ linux-2.6/drivers/net/irda/smsc-ircc2.c 2007-06-04 10:21:57.0
-0600
@@ -386,8 +386,8 @@
pnp_dma_valid(dev, 0) && pnp_irq_valid(dev, 0)))
return -EINVAL;
- sirbase = pnp_port_start(dev, 0);
- firbase = pnp_port_start(dev, 1);
+ firbase = pnp_port_start(dev, 0);
+ sirbase = pnp_port_start(dev, 1);
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 03 June 2007 02:16:05 am Andrey Borzenkov wrote:
On Sunday 03 June 2007, Andrey Borzenkov wrote:
Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
Nothing was changed in setup except kernel version.
2.6.21:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
The IrDA not enabled makes me think that even in the working case,
the BIOS left the IR port disabled. Are there any BIOS setup switches
that affect this port?
smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
SMsC IrDA Controller found
IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
It seems strange that both FIR and SIR would use legacy COM ports
(0x2f8 == COM2, 0x2e8 == COM4). My HP nw8240 has SIR at 0x3e8 (COM3)
and FIR at 0x100.
Do you know if both the FIR and SIR interfaces work? I'm wondering if
your irda0 only uses SIR at 0x2e8, and FIR has always been broken.
No transceiver found. Defaulting to Fast pin select
IrDA: Registered device irda0
2.6.22-rc3:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
The PNP probe I added expects SIR at the first range and FIR at the
second. I would think the 0x2e8 range would be SIR, since it's compatible
with a COM port. Is it possible the BIOS just reports these in the
opposite order, with FIR first and SIR second? Can you try the patch
below?
Index: linux-2.6/drivers/net/irda/smsc-ircc2.c
===
--- linux-2.6.orig/drivers/net/irda/smsc-ircc2.c2007-06-04
10:21:46.0 -0600
+++ linux-2.6/drivers/net/irda/smsc-ircc2.c 2007-06-04 10:21:57.0
-0600
@@ -386,8 +386,8 @@
pnp_dma_valid(dev, 0) pnp_irq_valid(dev, 0)))
return -EINVAL;
- sirbase = pnp_port_start(dev, 0);
- firbase = pnp_port_start(dev, 1);
+ firbase = pnp_port_start(dev, 0);
+ sirbase = pnp_port_start(dev, 1);
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
(Adding Linus Walleij, who wrote part of the smsc driver, to Cc:)
On Mon, Jun 04, 2007 at 06:33:56AM +0400, Andrey Borzenkov wrote:
On Monday 04 June 2007, Samuel Ortiz wrote:
It seems that PnP tells us that the FIR port is at 0x2e8 while we're
expecting it at 0x2f8.
Could you apply this patch and then send me a dmesg dump of the
smsc-ircc initialisation ?
here is dmesg:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_pnp_probe(): fir 0x2e8 sir 0x100 dma 1 irq 5
Ok, FIR and SIR are definitey mixed up. So, now could you please try Bjorn's
patch ? I wonder if the curent code (without PnP) enables 0x2f8 as the SIR
port through the preconfiguration code...
Cheers,
Samuel.
High: 0xef, Chip 0x1
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
And here is what PnP tells us:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/options
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,6,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = disabled
{pts/1}% sudo sh -c 'echo activate /sys/bus/pnp/devices/00:0a/resources'
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
-andrey
Cheers,
Samuel.
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..d1d46a6 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev
*dev, dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
+ printk(%s(): fir 0x%x sir 0x%x dma %d irq %d\n,
+ __FUNCTION__, firbase, sirbase, dma, irq);
+
if (smsc_ircc_open(firbase, sirbase, dma, irq))
return -ENODEV;
@@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
unsigned int sir_base) irq = (config IRCC_INTERFACE_IRQ_MASK) 4;
if (high != 0x10 || low != 0xb8 || (chip != 0xf1 chip != 0xf2)) {
+ printk(High: 0x%x, Chip 0x%x\n, high, chip);
IRDA_WARNING(%s(), addr 0x%04x - no device found!\n,
__FUNCTION__, fir_base);
goto out3;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 04 June 2007, Bjorn Helgaas wrote:
On Sunday 03 June 2007 02:16:05 am Andrey Borzenkov wrote:
On Sunday 03 June 2007, Andrey Borzenkov wrote:
Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
Nothing was changed in setup except kernel version.
2.6.21:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA
chip, pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
The IrDA not enabled makes me think that even in the working case,
the BIOS left the IR port disabled. Are there any BIOS setup switches
that affect this port?
No (at least in BIOS setup screens). The closest is COM port setting
(IRQ/DMA). This looks funny as I do not have COM interface anyway but may be
docking station has.
smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode:
0x02 SMsC IrDA Controller found
IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
It seems strange that both FIR and SIR would use legacy COM ports
(0x2f8 == COM2, 0x2e8 == COM4). My HP nw8240 has SIR at 0x3e8 (COM3)
and FIR at 0x100.
Well, this is how code was written. There was no autodetection anyway, it used
hardcoded builtin (unless overridden).
Do you know if both the FIR and SIR interfaces work? I'm wondering if
your irda0 only uses SIR at 0x2e8, and FIR has always been broken.
How can I check it?
No transceiver found. Defaulting to Fast pin select
IrDA: Registered device irda0
2.6.22-rc3:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA
chip, pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
The PNP probe I added expects SIR at the first range and FIR at the
second. I would think the 0x2e8 range would be SIR, since it's compatible
with a COM port. Is it possible the BIOS just reports these in the
opposite order, with FIR first and SIR second? Can you try the patch
below?
It does not work unfortunately:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_pnp_probe(): fir 0x100 sir 0x2e8 dma 1 irq 5
High: 0x11, Chip 0x0
smsc_ircc_present(), addr 0x0100 - no device found!
pnp: Device 00:0a disabled.
Index: linux-2.6/drivers/net/irda/smsc-ircc2.c
===
--- linux-2.6.orig/drivers/net/irda/smsc-ircc2.c 2007-06-04
10:21:46.0 -0600 +++
linux-2.6/drivers/net/irda/smsc-ircc2.c 2007-06-04 10:21:57.0
-0600
@@ -386,8 +386,8 @@
pnp_dma_valid(dev, 0) pnp_irq_valid(dev, 0)))
return -EINVAL;
- sirbase = pnp_port_start(dev, 0);
- firbase = pnp_port_start(dev, 1);
+ firbase = pnp_port_start(dev, 0);
+ sirbase = pnp_port_start(dev, 1);
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
signature.asc
Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Tuesday 05 June 2007, Samuel Ortiz wrote:
(Adding Linus Walleij, who wrote part of the smsc driver, to Cc:)
On Mon, Jun 04, 2007 at 06:33:56AM +0400, Andrey Borzenkov wrote:
On Monday 04 June 2007, Samuel Ortiz wrote:
It seems that PnP tells us that the FIR port is at 0x2e8 while we're
expecting it at 0x2f8.
Could you apply this patch and then send me a dmesg dump of the
smsc-ircc initialisation ?
here is dmesg:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_pnp_probe(): fir 0x2e8 sir 0x100 dma 1 irq 5
Ok, FIR and SIR are definitey mixed up. So, now could you please try
Bjorn's patch ?
does not work.
I wonder if the curent code (without PnP) enables 0x2f8 as
the SIR port through the preconfiguration code...
Cheers,
Samuel.
High: 0xef, Chip 0x1
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
And here is what PnP tells us:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/options
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,6,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = disabled
{pts/1}% sudo sh -c 'echo activate
/sys/bus/pnp/devices/00:0a/resources' {pts/1}% cat
/sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
-andrey
Cheers,
Samuel.
diff --git a/drivers/net/irda/smsc-ircc2.c
b/drivers/net/irda/smsc-ircc2.c index 9043bf4..d1d46a6 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct
pnp_dev *dev, dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
+ printk(%s(): fir 0x%x sir 0x%x dma %d irq %d\n,
+__FUNCTION__, firbase, sirbase, dma, irq);
+
if (smsc_ircc_open(firbase, sirbase, dma, irq))
return -ENODEV;
@@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
unsigned int sir_base) irq = (config IRCC_INTERFACE_IRQ_MASK)
4;
if (high != 0x10 || low != 0xb8 || (chip != 0xf1 chip != 0xf2)) {
+ printk(High: 0x%x, Chip 0x%x\n, high, chip);
IRDA_WARNING(%s(), addr 0x%04x - no device found!\n,
__FUNCTION__, fir_base);
goto out3;
signature.asc
Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 04 June 2007, Samuel Ortiz wrote:
> Hi Andrey,
>
> On Sun, Jun 03, 2007 at 12:16:05PM +0400, Andrey Borzenkov wrote:
> > Adding "nopnp" parameters finds device just fine so it is apparently
> > result of this commit:
> >
> > commit d0d4f69bb65a8c1c1430c577a583632709b874c6
> > Author: Bjorn Helgaas <[EMAIL PROTECTED]>
> > Date: Tue May 8 00:36:05 2007 -0700
> >
> > smsc-ircc2: add PNP support
> >
> > What information is needed to debug it further?
>
> It seems that PnP tells us that the FIR port is at 0x2e8 while we're
> expecting it at 0x2f8.
> Could you apply this patch and then send me a dmesg dump of the
> smsc-ircc initialisation ?
>
here is dmesg:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_pnp_probe(): fir 0x2e8 sir 0x100 dma 1 irq 5
High: 0xef, Chip 0x1
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
And here is what PnP tells us:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/options
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,6,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = disabled
{pts/1}% sudo sh -c 'echo activate > /sys/bus/pnp/devices/00:0a/resources'
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
-andrey
> Cheers,
> Samuel.
>
>
> diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
> index 9043bf4..d1d46a6 100644
> --- a/drivers/net/irda/smsc-ircc2.c
> +++ b/drivers/net/irda/smsc-ircc2.c
> @@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev
> *dev, dma = pnp_dma(dev, 0);
> irq = pnp_irq(dev, 0);
>
> + printk("%s(): fir 0x%x sir 0x%x dma %d irq %d\n",
> +__FUNCTION__, firbase, sirbase, dma, irq);
> +
> if (smsc_ircc_open(firbase, sirbase, dma, irq))
> return -ENODEV;
>
> @@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
> unsigned int sir_base) irq = (config & IRCC_INTERFACE_IRQ_MASK) >> 4;
>
> if (high != 0x10 || low != 0xb8 || (chip != 0xf1 && chip != 0xf2)) {
> + printk("High: 0x%x, Chip 0x%x\n", high, chip);
> IRDA_WARNING("%s(), addr 0x%04x - no device found!\n",
>__FUNCTION__, fir_base);
> goto out3;
signature.asc
Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Andrey,
On Sun, Jun 03, 2007 at 12:16:05PM +0400, Andrey Borzenkov wrote:
>
> Adding "nopnp" parameters finds device just fine so it is apparently result
> of
> this commit:
>
> commit d0d4f69bb65a8c1c1430c577a583632709b874c6
> Author: Bjorn Helgaas <[EMAIL PROTECTED]>
> Date: Tue May 8 00:36:05 2007 -0700
>
> smsc-ircc2: add PNP support
>
> What information is needed to debug it further?
It seems that PnP tells us that the FIR port is at 0x2e8 while we're
expecting it at 0x2f8.
Could you apply this patch and then send me a dmesg dump of the
smsc-ircc initialisation ?
Cheers,
Samuel.
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..d1d46a6 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev *dev,
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
+ printk("%s(): fir 0x%x sir 0x%x dma %d irq %d\n",
+ __FUNCTION__, firbase, sirbase, dma, irq);
+
if (smsc_ircc_open(firbase, sirbase, dma, irq))
return -ENODEV;
@@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
unsigned int sir_base)
irq = (config & IRCC_INTERFACE_IRQ_MASK) >> 4;
if (high != 0x10 || low != 0xb8 || (chip != 0xf1 && chip != 0xf2)) {
+ printk("High: 0x%x, Chip 0x%x\n", high, chip);
IRDA_WARNING("%s(), addr 0x%04x - no device found!\n",
__FUNCTION__, fir_base);
goto out3;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 03 June 2007, Andrey Borzenkov wrote:
> Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
> Nothing was changed in setup except kernel version.
>
> 2.6.21:
>
> Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
> pre-configuring device.
> Activated ALi 1533 ISA bridge port 0x02e8.
> Activated ALi 1533 ISA bridge port 0x02f8.
> found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
> smsc_superio_flat(): IrDA not enabled
> smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
> SMsC IrDA Controller found
> IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
> No transceiver found. Defaulting to Fast pin select
> IrDA: Registered device irda0
>
>
> 2.6.22-rc3:
> Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
> pre-configuring device.
> Activated ALi 1533 ISA bridge port 0x02e8.
> Activated ALi 1533 ISA bridge port 0x02f8.
> pnp: Device 00:0a activated.
> smsc_ircc_present(), addr 0x02e8 - no device found!
> pnp: Device 00:0a disabled.
>
> I Cc Adam because of pnp messages in this case - they were not present in
> 2.6.21 so something is being done differently now.
>
> Some more info:
>
> {pts/1}% cat /sys/bus/pnp/devices/00:0a/id
> SMCf010
> {pts/1}% lspci -nn
> 00:00.0 Host bridge [0600]: ALi Corporation M1644/M1644T
> Northbridge+Trident [10b9:1644] (rev 01)
> 00:01.0 PCI bridge [0604]: ALi Corporation PCI to AGP Controller
> [10b9:5247] 00:02.0 USB Controller [0c03]: ALi Corporation USB 1.1
> Controller [10b9:5237] (rev 03)
> 00:04.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev
> c3) 00:06.0 Multimedia audio controller [0401]: ALi Corporation M5451 PCI
> AC-Link Controller Audio Device [10b9:5451] (rev 01)
> 00:07.0 ISA bridge [0601]: ALi Corporation M1533/M1535 PCI to ISA Bridge
> [Aladdin IV/V/V+] [10b9:1533]
> 00:08.0 Bridge [0680]: ALi Corporation M7101 Power Management Controller
> [PMU] [10b9:7101]
> 00:0a.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet
> Pro 100] [8086:1229] (rev 08)
> 00:10.0 CardBus bridge [0607]: Texas Instruments PCI1410 PC card Cardbus
> Controller [104c:ac50] (rev 01)
> 00:11.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
> Cardbus Bridge with ZV Support [1179:0617] (rev 32)
> 00:11.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
> Cardbus Bridge with ZV Support [1179:0617] (rev 32)
> 00:12.0 System peripheral [0880]: Toshiba America Info Systems SD TypA
> Controller [1179:0805] (rev 03)
> 01:00.0 VGA compatible controller [0300]: Trident Microsystems CyberBlade
> XPAi1 [1023:8820] (rev 82)
>
> config from 2.6.22-rc3 attached.
>
Adding "nopnp" parameters finds device just fine so it is apparently result of
this commit:
commit d0d4f69bb65a8c1c1430c577a583632709b874c6
Author: Bjorn Helgaas <[EMAIL PROTECTED]>
Date: Tue May 8 00:36:05 2007 -0700
smsc-ircc2: add PNP support
What information is needed to debug it further?
-andrey
signature.asc
Description: This is a digitally signed message part.
2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
Nothing was changed in setup except kernel version.
2.6.21:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
SMsC IrDA Controller found
IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
No transceiver found. Defaulting to Fast pin select
IrDA: Registered device irda0
2.6.22-rc3:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
I Cc Adam because of pnp messages in this case - they were not present in
2.6.21 so something is being done differently now.
Some more info:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/id
SMCf010
{pts/1}% lspci -nn
00:00.0 Host bridge [0600]: ALi Corporation M1644/M1644T Northbridge+Trident
[10b9:1644] (rev 01)
00:01.0 PCI bridge [0604]: ALi Corporation PCI to AGP Controller [10b9:5247]
00:02.0 USB Controller [0c03]: ALi Corporation USB 1.1 Controller [10b9:5237]
(rev 03)
00:04.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev c3)
00:06.0 Multimedia audio controller [0401]: ALi Corporation M5451 PCI AC-Link
Controller Audio Device [10b9:5451] (rev 01)
00:07.0 ISA bridge [0601]: ALi Corporation M1533/M1535 PCI to ISA Bridge
[Aladdin IV/V/V+] [10b9:1533]
00:08.0 Bridge [0680]: ALi Corporation M7101 Power Management Controller [PMU]
[10b9:7101]
00:0a.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet Pro
100] [8086:1229] (rev 08)
00:10.0 CardBus bridge [0607]: Texas Instruments PCI1410 PC card Cardbus
Controller [104c:ac50] (rev 01)
00:11.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
Cardbus Bridge with ZV Support [1179:0617] (rev 32)
00:11.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
Cardbus Bridge with ZV Support [1179:0617] (rev 32)
00:12.0 System peripheral [0880]: Toshiba America Info Systems SD TypA
Controller [1179:0805] (rev 03)
01:00.0 VGA compatible controller [0300]: Trident Microsystems CyberBlade
XPAi1 [1023:8820] (rev 82)
config from 2.6.22-rc3 attached.
-andrey
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc3
# Sun Jun 3 00:02:29 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_SMP is not set
2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
Nothing was changed in setup except kernel version.
2.6.21:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
SMsC IrDA Controller found
IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
No transceiver found. Defaulting to Fast pin select
IrDA: Registered device irda0
2.6.22-rc3:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
I Cc Adam because of pnp messages in this case - they were not present in
2.6.21 so something is being done differently now.
Some more info:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/id
SMCf010
{pts/1}% lspci -nn
00:00.0 Host bridge [0600]: ALi Corporation M1644/M1644T Northbridge+Trident
[10b9:1644] (rev 01)
00:01.0 PCI bridge [0604]: ALi Corporation PCI to AGP Controller [10b9:5247]
00:02.0 USB Controller [0c03]: ALi Corporation USB 1.1 Controller [10b9:5237]
(rev 03)
00:04.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev c3)
00:06.0 Multimedia audio controller [0401]: ALi Corporation M5451 PCI AC-Link
Controller Audio Device [10b9:5451] (rev 01)
00:07.0 ISA bridge [0601]: ALi Corporation M1533/M1535 PCI to ISA Bridge
[Aladdin IV/V/V+] [10b9:1533]
00:08.0 Bridge [0680]: ALi Corporation M7101 Power Management Controller [PMU]
[10b9:7101]
00:0a.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet Pro
100] [8086:1229] (rev 08)
00:10.0 CardBus bridge [0607]: Texas Instruments PCI1410 PC card Cardbus
Controller [104c:ac50] (rev 01)
00:11.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
Cardbus Bridge with ZV Support [1179:0617] (rev 32)
00:11.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
Cardbus Bridge with ZV Support [1179:0617] (rev 32)
00:12.0 System peripheral [0880]: Toshiba America Info Systems SD TypA
Controller [1179:0805] (rev 03)
01:00.0 VGA compatible controller [0300]: Trident Microsystems CyberBlade
XPAi1 [1023:8820] (rev 82)
config from 2.6.22-rc3 attached.
-andrey
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.22-rc3
# Sun Jun 3 00:02:29 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST=/lib/modules/$UNAME_RELEASE/.config
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=17
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=
# CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED=cfq
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
# CONFIG_SMP is not set
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Sunday 03 June 2007, Andrey Borzenkov wrote:
Under 2.6.22-rc I lost irda0 interface - smsc claims no device present.
Nothing was changed in setup except kernel version.
2.6.21:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
found SMC SuperIO Chip (devid=0x5a rev=00 base=0x002e): LPC47N227
smsc_superio_flat(): IrDA not enabled
smsc_superio_flat(): fir: 0x2f8, sir: 0x2e8, dma: 03, irq: 7, mode: 0x02
SMsC IrDA Controller found
IrCC version 2.0, firport 0x2f8, sirport 0x2e8 dma=3, irq=7
No transceiver found. Defaulting to Fast pin select
IrDA: Registered device irda0
2.6.22-rc3:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
I Cc Adam because of pnp messages in this case - they were not present in
2.6.21 so something is being done differently now.
Some more info:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/id
SMCf010
{pts/1}% lspci -nn
00:00.0 Host bridge [0600]: ALi Corporation M1644/M1644T
Northbridge+Trident [10b9:1644] (rev 01)
00:01.0 PCI bridge [0604]: ALi Corporation PCI to AGP Controller
[10b9:5247] 00:02.0 USB Controller [0c03]: ALi Corporation USB 1.1
Controller [10b9:5237] (rev 03)
00:04.0 IDE interface [0101]: ALi Corporation M5229 IDE [10b9:5229] (rev
c3) 00:06.0 Multimedia audio controller [0401]: ALi Corporation M5451 PCI
AC-Link Controller Audio Device [10b9:5451] (rev 01)
00:07.0 ISA bridge [0601]: ALi Corporation M1533/M1535 PCI to ISA Bridge
[Aladdin IV/V/V+] [10b9:1533]
00:08.0 Bridge [0680]: ALi Corporation M7101 Power Management Controller
[PMU] [10b9:7101]
00:0a.0 Ethernet controller [0200]: Intel Corporation 82557/8/9 [Ethernet
Pro 100] [8086:1229] (rev 08)
00:10.0 CardBus bridge [0607]: Texas Instruments PCI1410 PC card Cardbus
Controller [104c:ac50] (rev 01)
00:11.0 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
Cardbus Bridge with ZV Support [1179:0617] (rev 32)
00:11.1 CardBus bridge [0607]: Toshiba America Info Systems ToPIC100 PCI to
Cardbus Bridge with ZV Support [1179:0617] (rev 32)
00:12.0 System peripheral [0880]: Toshiba America Info Systems SD TypA
Controller [1179:0805] (rev 03)
01:00.0 VGA compatible controller [0300]: Trident Microsystems CyberBlade
XPAi1 [1023:8820] (rev 82)
config from 2.6.22-rc3 attached.
Adding nopnp parameters finds device just fine so it is apparently result of
this commit:
commit d0d4f69bb65a8c1c1430c577a583632709b874c6
Author: Bjorn Helgaas [EMAIL PROTECTED]
Date: Tue May 8 00:36:05 2007 -0700
smsc-ircc2: add PNP support
What information is needed to debug it further?
-andrey
signature.asc
Description: This is a digitally signed message part.
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
Hi Andrey,
On Sun, Jun 03, 2007 at 12:16:05PM +0400, Andrey Borzenkov wrote:
Adding nopnp parameters finds device just fine so it is apparently result
of
this commit:
commit d0d4f69bb65a8c1c1430c577a583632709b874c6
Author: Bjorn Helgaas [EMAIL PROTECTED]
Date: Tue May 8 00:36:05 2007 -0700
smsc-ircc2: add PNP support
What information is needed to debug it further?
It seems that PnP tells us that the FIR port is at 0x2e8 while we're
expecting it at 0x2f8.
Could you apply this patch and then send me a dmesg dump of the
smsc-ircc initialisation ?
Cheers,
Samuel.
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..d1d46a6 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev *dev,
dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
+ printk(%s(): fir 0x%x sir 0x%x dma %d irq %d\n,
+ __FUNCTION__, firbase, sirbase, dma, irq);
+
if (smsc_ircc_open(firbase, sirbase, dma, irq))
return -ENODEV;
@@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
unsigned int sir_base)
irq = (config IRCC_INTERFACE_IRQ_MASK) 4;
if (high != 0x10 || low != 0xb8 || (chip != 0xf1 chip != 0xf2)) {
+ printk(High: 0x%x, Chip 0x%x\n, high, chip);
IRDA_WARNING(%s(), addr 0x%04x - no device found!\n,
__FUNCTION__, fir_base);
goto out3;
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc: regression: no irda0 interface (2.6.21 was OK), smsc does not find chip
On Monday 04 June 2007, Samuel Ortiz wrote:
Hi Andrey,
On Sun, Jun 03, 2007 at 12:16:05PM +0400, Andrey Borzenkov wrote:
Adding nopnp parameters finds device just fine so it is apparently
result of this commit:
commit d0d4f69bb65a8c1c1430c577a583632709b874c6
Author: Bjorn Helgaas [EMAIL PROTECTED]
Date: Tue May 8 00:36:05 2007 -0700
smsc-ircc2: add PNP support
What information is needed to debug it further?
It seems that PnP tells us that the FIR port is at 0x2e8 while we're
expecting it at 0x2f8.
Could you apply this patch and then send me a dmesg dump of the
smsc-ircc initialisation ?
here is dmesg:
Detected unconfigured Toshiba laptop with ALi ISA bridge SMSC IrDA chip,
pre-configuring device.
Activated ALi 1533 ISA bridge port 0x02e8.
Activated ALi 1533 ISA bridge port 0x02f8.
pnp: Device 00:0a activated.
smsc_ircc_pnp_probe(): fir 0x2e8 sir 0x100 dma 1 irq 5
High: 0xef, Chip 0x1
smsc_ircc_present(), addr 0x02e8 - no device found!
pnp: Device 00:0a disabled.
And here is what PnP tells us:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/options
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding
irq 3,4,5,6,7,10,11 High-Edge
dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 02 - Priority acceptable
port 0x2e8-0x2e8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 03 - Priority acceptable
port 0x2f8-0x2f8, align 0x0, size 0x8, 16-bit address decoding
Dependent: 04 - Priority acceptable
port 0x3e8-0x3e8, align 0x0, size 0x8, 16-bit address decoding
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = disabled
{pts/1}% sudo sh -c 'echo activate /sys/bus/pnp/devices/00:0a/resources'
{pts/1}% cat /sys/bus/pnp/devices/00:0a/resources
state = active
io 0x100-0x107
io 0x2e8-0x2ef
irq 5
dma 1
-andrey
Cheers,
Samuel.
diff --git a/drivers/net/irda/smsc-ircc2.c b/drivers/net/irda/smsc-ircc2.c
index 9043bf4..d1d46a6 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -391,6 +391,9 @@ static int __init smsc_ircc_pnp_probe(struct pnp_dev
*dev, dma = pnp_dma(dev, 0);
irq = pnp_irq(dev, 0);
+ printk(%s(): fir 0x%x sir 0x%x dma %d irq %d\n,
+__FUNCTION__, firbase, sirbase, dma, irq);
+
if (smsc_ircc_open(firbase, sirbase, dma, irq))
return -ENODEV;
@@ -655,6 +658,7 @@ static int smsc_ircc_present(unsigned int fir_base,
unsigned int sir_base) irq = (config IRCC_INTERFACE_IRQ_MASK) 4;
if (high != 0x10 || low != 0xb8 || (chip != 0xf1 chip != 0xf2)) {
+ printk(High: 0x%x, Chip 0x%x\n, high, chip);
IRDA_WARNING(%s(), addr 0x%04x - no device found!\n,
__FUNCTION__, fir_base);
goto out3;
signature.asc
Description: This is a digitally signed message part.
