On Toshiba Satellite (i386):
yenta_cardbus 0000:01:0b.0: ISA IRQ mask 0x0c38, PCI irq 18
yenta_cardbus 0000:01:0b.0: Socket status: 30000020
yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge I/O window: 0xc000 - 0xcfff
: cs: IO port probe 0xc000-0xcfff: clean.
^^--- missing device ID
Note that a bit later the device ID _is_ present in the same message:
yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge Memory window: 0xcfe00000 - 0xcfefffff
yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge Memory window: 0x28000000 - 0x2bffffff
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x3e0-0x4ff: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0x820-0x8ff: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xc00-0xcf7: clean.
pcmcia_socket pcmcia_socket0: cs: IO port probe 0xa00-0xaff: clean.
Due to:
commit dbe4ea5fde198a3808e46b665d889818c1e600f5
Author: Dominik Brodowski <[email protected]>
Date: Sat Aug 2 21:36:19 2008 +0200
pcmcia: use dev_printk in module rsrc_nonstatic
On HP 2510p (x86_64):
rtc_cmos 00:06: RTC can wake from S4
rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
^^^^^^^^^--- "irqs" repeated
^^--- missing value?
Due to:
commit c8fc40cd345bfd88d8a98e7916909b9143502999
Author: David Brownell <[email protected]>
Date: Sat Oct 18 20:27:47 2008 -0700
rtc-cmos: export second NVRAM bank
Cheers,
FJP
On Monday 03 November 2008, Frans Pop wrote:
> rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
Here's a possible patch for this one.
Alternative would be to change the following line at 808:
is_hpet_enabled() ? ", hpet irqs" : "");
to:
is_hpet_enabled() ? "hpet" : "<sensible value>");
Question is what that sensible value would be...
---
From: Frans Pop <[email protected]>
rtc-cmos: Fix boot log message
-rtc0: alarms up to one month, y3k, 114 bytes nvram, , hpet irqs irqs
+rtc0: alarms up to one month, y3k, 114 bytes nvram, hpet irqs
Signed-off-by: Frans Pop <[email protected]>
diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index 5549231..6cf8e28 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -794,7 +794,7 @@ cmos_do_probe(struct device *dev, struct resource *ports, int rtc_irq)
goto cleanup2;
}
- pr_info("%s: alarms up to one %s%s, %zd bytes nvram, %s irqs\n",
+ pr_info("%s: alarms up to one %s%s, %zd bytes nvram%s\n",
cmos_rtc.rtc->dev.bus_id,
is_valid_irq(rtc_irq)
? (cmos_rtc.mon_alrm
On Monday 03 November 2008, Frans Pop wrote:
> Alternative would be to change the following line at 808:
> ????????????????????????is_hpet_enabled() ? ", hpet irqs" : "");
> to:
> ????????????????????????is_hpet_enabled() ? "hpet" : "<sensible value>");
The intent was "hpet irqs" vs "native IRQs" (typical PC options)
vs "no irqs" (e.g. on SPARCs).
I think fixes got trashed when the patch queue got corrupted
by some queue-jumping ... see the patch in
http://bugzilla.kernel.org/show_bug.cgi?id=11153
which was broken by a474aaedac99ba86e28ef6c912a7647c482db6dd,
and has appropriately sane messaging.
- Dave
On Tuesday 04 November 2008, David Brownell wrote:
> On Monday 03 November 2008, Frans Pop wrote:
> > Alternative would be to change the following line at 808:
> > ????????????????????????is_hpet_enabled() ? ", hpet irqs" : "");
> > to:
> > ????????????????????????is_hpet_enabled() ? "hpet" : "<sensible
> > value>");
>
> The intent was "hpet irqs" vs "native IRQs" (typical PC options)
> vs "no irqs" (e.g. on SPARCs).
>
> I think fixes got trashed when the patch queue got corrupted
> by some queue-jumping ... see the patch in
>
> http://bugzilla.kernel.org/show_bug.cgi?id=11153
>
> which was broken by a474aaedac99ba86e28ef6c912a7647c482db6dd,
> and has appropriately sane messaging.
AFAICT that patch is still pending, which means that the patch I proposed
should be good and fix the "regression".
When your original patch is then updated against git head and resubmitted,
things should still end up as you intended.
Cheers,
FJP
Frans Pop wrote:
> On Toshiba Satellite (i386):
> yenta_cardbus 0000:01:0b.0: ISA IRQ mask 0x0c38, PCI irq 18
> yenta_cardbus 0000:01:0b.0: Socket status: 30000020
> yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge I/O window: 0xc000 - 0xcfff
> : cs: IO port probe 0xc000-0xcfff: clean.
> ^^--- missing device ID
>
> Note that a bit later the device ID _is_ present in the same message:
> yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge Memory window: 0xcfe00000 - 0xcfefffff
> yenta_cardbus 0000:01:0b.0: pcmcia: parent PCI bridge Memory window: 0x28000000 - 0x2bffffff
> pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
> pcmcia_socket pcmcia_socket0: cs: IO port probe 0x100-0x3af: clean.
The following patch fixes this issue and also fixes another minor error.
The patch prefixes "yenta_cardbus 0000:01:0b.0" for the first IO probe and
leaves the later ones unchanged.
Alternative would be to just unconditionally use &s->cb_dev->dev.
It might be good to clean up the seemingly inconsistent use in the messages
of "pcmcia: ", "pccard: " and "cs: " at some point. (Or even just just remove
them altogether as they are now redundant?)
Cheers,
FJP
---
From: Frans Pop <[email protected]>
pcmcia: ensure correct logging in do_io_probe
During early probing of the parent PCI bridge I/O window no socket
has been allocated yet.
In that case print &s->cb_dev->dev instead of &s->dev as device.
Also properly close previous dev_printk if kzalloc fails.
Signed-off-by: Frans Pop <[email protected]>
diff --git a/drivers/pcmcia/rsrc_nonstatic.c b/drivers/pcmcia/rsrc_nonstatic.c
index 17f4ecf..2a6a3d1 100644
--- a/drivers/pcmcia/rsrc_nonstatic.c
+++ b/drivers/pcmcia/rsrc_nonstatic.c
@@ -200,14 +200,17 @@ static void do_io_probe(struct pcmcia_socket *s, unsigned int base,
int any;
u_char *b, hole, most;
- dev_printk(KERN_INFO, &s->dev, "cs: IO port probe %#x-%#x:",
- base, base+num-1);
+ dev_printk(KERN_INFO,
+ s->state & SOCKET_PRESENT ? &s->dev : &s->cb_dev->dev,
+ "cs: IO port probe %#x-%#x:", base, base+num-1);
/* First, what does a floating port look like? */
b = kzalloc(256, GFP_KERNEL);
if (!b) {
- dev_printk(KERN_ERR, &s->dev,
- "do_io_probe: unable to kmalloc 256 bytes");
+ printk("\n");
+ dev_printk(KERN_ERR,
+ s->state & SOCKET_PRESENT ? &s->dev : &s->cb_dev->dev,
+ "cs: do_io_probe: unable to kmalloc 256 bytes");
return;
}
for (i = base, most = 0; i < base+num; i += 8) {
From: Frans Pop <[email protected]>
pcmcia: minor logging improvement on card detection
Show for which device a card has been inserted, so instead of:
pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
print:
yenta_cardbus 0000:01:0b.0: pccard: CardBus card inserted into slot 0
This provides a more logical link between previous and following messages.
Signed-off-by: Frans Pop <[email protected]>
CC: Dominik Brodowski <[email protected]>
diff --git a/drivers/pcmcia/cs.c b/drivers/pcmcia/cs.c
index c68c5d3..c249776 100644
--- a/drivers/pcmcia/cs.c
+++ b/drivers/pcmcia/cs.c
@@ -510,7 +510,7 @@ static int socket_insert(struct pcmcia_socket *skt)
if (ret == 0) {
skt->state |= SOCKET_PRESENT;
- dev_printk(KERN_NOTICE, &skt->dev,
+ dev_printk(KERN_NOTICE, &skt->cb_dev->dev,
"pccard: %s card inserted into slot %d\n",
(skt->state & SOCKET_CARDBUS) ? "CardBus" : "PCMCIA",
skt->sock);
Hi,
On Fri, Nov 07, 2008 at 02:35:15PM +0100, Frans Pop wrote:
> From: Frans Pop <[email protected]>
>
> pcmcia: minor logging improvement on card detection
>
> Show for which device a card has been inserted, so instead of:
> pcmcia_socket pcmcia_socket0: pccard: CardBus card inserted into slot 0
> print:
> yenta_cardbus 0000:01:0b.0: pccard: CardBus card inserted into slot 0
>
> This provides a more logical link between previous and following messages.
unfortunately, this won't work -- &skt->cb_dev is only available and set if
the parent device is a PCI device; therefore, &skt->dev is the only thing we
can use.
Best,
Dominik