Re: some PCMCIA SCSI drivers can be built *only* as modules
On Mon, Mar 26, 2007 at 04:06:53PM -0500, James Bottomley wrote: On Mon, 2007-03-26 at 21:38 +0100, Christoph Hellwig wrote: On Mon, Mar 26, 2007 at 03:35:47PM -0500, James Bottomley wrote: I agree the non-legacy (CardBus and beyond) ones can be built in. I thought the legacy 8 and 16 bit type I and II still had to be modular because they still need setting up. nope. While I don't have a pcmcia scsi card my 16 bit pcmcia wireless cards work perfectly fine without any previous setup. OK ... I had the opposite experience ... A ZoomAir 802.11b card wasn't working because I'd accidentally config'd it non-modular. However, if Dominik confirms it's all supposed to work non-modular. PCMCIA card drivers should (famous last words) work just fine if built as modules. They may not be bound to devices, depending on the arch and system, until userspace tools have run, but this is independent of modular or built-in drivers. So a full ACK on this. Thanks, Dominik - 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: [PATCH v3] pcmcia: Convert io_req_t to use unsigned int
On Fri, Oct 19, 2007 at 03:17:20PM -0500, Olof Johansson wrote: Convert the io_req_t members to unsigned int, to allow use on machines with more than 16 bits worth of IO ports (i.e. secondary busses on ppc64, etc). Agreed, though I'd prefer if we got rid of kio_addr_t at the same time, and convert its users to unsigned int as well -- as was pointed out earlier in this thread, there's no known usage of IO ports larger than 32 bits. Dominik - 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: [RFC] [PATCH] cpufreq: allow full selection of default governors
On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote: On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote: On 4/24/07, Dave Jones [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner wrote: The following patches should allow selection of conservative, powersave, and ondemand in the kernel configuration. This has been rejected several times already. Ondemand and conservative isn't a viable governor for all cpufreq implementations (ie, ones with high switching latencies). This piques my curiosity -- some governors don't work with some cpufreq implementations. Are those implementations in the kernel or in userspace? If in the kernel, then perhaps there should be some dependency expressed there in Kconfig between cpufreq implementation and the available governors it can't be solved that easily. powernow-k8 for example is fine to use with ondemand on newer systems, where the latency is low. On older models however, it isn't. Also, see the comment in the Kconfig a few lines above where you are adding this. Are these governors unfixable? If tbh, I've forgotten the original issues that caused the comment to be placed there. Dominik ? Not unfixable, but: cpufreq is currently[*] built around the assumption that at least one governor is correctly initialized or can be brought to work when a CPU is registered with the cpufreq core. Dominik [*] That is, the last time I looked at it ;) - 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: [RFC] [PATCH] cpufreq: allow full selection of default governors
On Fri, Apr 27, 2007 at 02:09:57AM -0400, Dave Jones wrote: On Thu, Apr 26, 2007 at 09:54:10PM -0400, Dominik Brodowski wrote: On Tue, Apr 24, 2007 at 08:03:27PM -0400, Dave Jones wrote: On Tue, Apr 24, 2007 at 03:05:36PM -0700, Nish Aravamudan wrote: On 4/24/07, Dave Jones [EMAIL PROTECTED] wrote: On Tue, Apr 24, 2007 at 09:03:23PM +, William Heimbigner wrote: The following patches should allow selection of conservative, powersave, and ondemand in the kernel configuration. This has been rejected several times already. Ondemand and conservative isn't a viable governor for all cpufreq implementations (ie, ones with high switching latencies). This piques my curiosity -- some governors don't work with some cpufreq implementations. Are those implementations in the kernel or in userspace? If in the kernel, then perhaps there should be some dependency expressed there in Kconfig between cpufreq implementation and the available governors it can't be solved that easily. powernow-k8 for example is fine to use with ondemand on newer systems, where the latency is low. On older models however, it isn't. Also, see the comment in the Kconfig a few lines above where you are adding this. Are these governors unfixable? If tbh, I've forgotten the original issues that caused the comment to be placed there. Dominik ? Not unfixable, but: cpufreq is currently[*] built around the assumption that at least one governor is correctly initialized or can be brought to work when a CPU is registered with the cpufreq core. It would have to take something fairly spectacular though for performance or powersave to fail registration. Can you remember why we chose not to allow those? performance _is_ allowed; powersave would be possible -- but then those who accidentally enable it on elanfreq might wait 100 times as long for the system to boot, with gx-suspmod it might even be 255 times as long -- okay, by default it's just 20 times as long, but still... Dominik - 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: PROBLEM: CompactFlash mount Oops
Hi, The problem seems to be cs: pcmcia_socket0: voltage interrogation timed out. Can you try passing the parameter setup_delay=50 to the module named pcmcia, please? Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi,
On Tue, Apr 19, 2005 at 04:56:56PM +0200, Thomas Renninger wrote:
If CONFIG_IDLE_HZ is set, the c-state will be evaluated on
three control values (averages of the last 4 measures):
a) idle_ms - if machine was active for longer than this
value (avg), the machine is assumed to not be idle
and C1 will be triggered.
b) bm_promote_ms - if the avg bus master activity is below
this threshold, C2 is invoked.
c) sleep_avg (no module param) - the average sleep time of the
last four C2 (or higher) invokations.
If a and b does not apply, a C-state will be searched that has
the highest latency, but still has a latency below the latest
C2 (or higher) sleeping time and average sleeping time value.
I think that we don't need this complication:
+//#define DEBUG 1
+#ifdef DEBUG
+#define myPrintk(string, args...) printk(KERN_INFO string, ##args);
+#else
+#define myPrintk(string, args...) {};
+#endif
Please don't do that... dprintk() is much more common. Also, then don't
comment dprintk() out below in the patch...
if (pr-flags.bm_check) {
- u32 bm_status = 0;
- unsigned long diff = jiffies - pr-power.bm_check_timestamp;
-
- if (diff 32)
- diff = 32;
-
- while (diff) {
- /* if we didn't get called, assume there was busmaster
activity */
- diff--;
- if (diff)
- pr-power.bm_activity |= 0x1;
- pr-power.bm_activity = 1;
- }
All we need to do is to update the diff. Without dynamic ticks, if the
idle loop didn't get called each jiffy, it was a big hint that there was so
much activity in between, and if there is activity, there is most likely
also bus master activity, or at least more work to do, so interrupt activity
is likely. Therefore we assume there was bm_activity even if there was none.
Now, we do know the jiffy value when we started sleeping. If we use
ticks_elapsed(t1, t2), convert it to jiffies, and do
diff = jiffies - (pr-power.bm_check_timestamp + last_sleep_jiffies);
it should work. I wrote a quick patch to do that, but it locked up my
notebook, so it is most likely broken; hopefully I'll find some time to debug
it, if somebody does it earlier, that'd be great, though.
Thanks,
Dominik
Only assume busmaster activity on non-idle ticks if we didn't sleep until
that jiffy. Needed for dyn-idle.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
--- linux/drivers/acpi/processor_idle.c.original2005-04-10
20:04:12.0 +0200
+++ linux/drivers/acpi/processor_idle.c 2005-04-10 20:14:33.0 +0200
@@ -120,6 +120,14 @@
return ((0x - t1) + t2);
}
+static inline u32
+ticks_to_jiffies (u32 pm_ticks)
+{
+ pm_ticks *= 286;
+ pm_ticks = (pm_ticks 10);
+ return (pm_ticks / (USEC_PER_SEC / HZ));
+}
+
static void
acpi_processor_power_activate (
@@ -169,7 +177,7 @@
struct acpi_processor_cx *cx = NULL;
struct acpi_processor_cx *next_state = NULL;
int sleep_ticks = 0;
- u32 t1, t2 = 0;
+ u32 t1, t2, td = 0;
pr = processors[_smp_processor_id()];
if (!pr)
@@ -201,11 +209,13 @@
* for demotion.
*/
if (pr-flags.bm_check) {
- u32 bm_status = 0;
- unsigned long diff = jiffies - pr-power.bm_check_timestamp;
+ u32 bm_status = 0;
+ longdiff = jiffies - pr-power.bm_check_timestamp;
if (diff 32)
diff = 32;
+ else if (diff 0)
+ diff = 0;
while (diff) {
/* if we didn't get called, assume there was busmaster
activity */
@@ -293,7 +303,9 @@
/* Re-enable interrupts */
local_irq_enable();
/* Compute time (ticks) that we were actually asleep */
- sleep_ticks = ticks_elapsed(t1, t2) - cx-latency_ticks -
C2_OVERHEAD;
+ td = ticks_elapsed(t1, t2);
+ sleep_ticks = td - cx-latency_ticks - C2_OVERHEAD;
+ pr-power.bm_check_timestamp += ticks_to_jiffies(td);
break;
case ACPI_STATE_C3:
@@ -312,7 +324,9 @@
/* Re-enable interrupts */
local_irq_enable();
/* Compute time (ticks) that we were actually asleep */
- sleep_ticks = ticks_elapsed(t1, t2) - cx-latency_ticks -
C3_OVERHEAD;
+ td = ticks_elapsed(t1, t2);
+ sleep_ticks = td - cx-latency_ticks - C3_OVERHEAD;
+ pr-power.bm_check_timestamp += ticks_to_jiffies(td);
break;
default:
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Re: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
On Tue, Apr 19, 2005 at 11:03:30PM +0200, Thomas Renninger wrote: All we need to do is to update the diff. Without dynamic ticks, if the idle loop didn't get called each jiffy, it was a big hint that there was so much activity in between, and if there is activity, there is most likely also bus master activity, or at least more work to do, so interrupt activity is likely. Therefore we assume there was bm_activity even if there was none. If I understand this right you want at least wait 32 (or whatever value) ms if there was bm activity, before it is allowed to trigger C3/C4? That's the theory of operation of the current algorithm. I think that we should do that small change to the current algorithm which allows us to keep C3/C4 working with dyn-idle first, and then think of a very small abstraction layer to test different idle algroithms, and -- possibly -- use different ones for different usages. I think the problem is (at least I made the experience with this particular machine) that bm activity comes very often and regularly (each 30-150ms?). I think the approach to directly adjust the latency to a deeper sleep state if the average bus master and OS activity is low is very efficient. Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. The patch is useless if these failures end up in system freezes on other machines... I know that my patch is useless in its current form, but I wanted to share it as a different way of doing things. The problem with the old approach is, that after (doesn't matter C1-Cx) sleep and dyn_idle_tick, the chance to wake up because of bm activity is very likely. You enter idle() again - there was bm_activity - C2. Wake up after e.g. 50ms, because of bm_activity again (bm_sts bit set) - stay in C2, wake up after 40ms - bm activity... You only have the chance to get into deeper states if the sleeps are interrupted by an interrupt, not bm activity. That's a side-effect, indeed. However: if there _is_ bus master activity, we must not enter C3, AFAICS. Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
On Wed, Apr 20, 2005 at 01:57:39PM +0200, Pavel Machek wrote: Hi! Because I don't consider whether there was bm_activity the last ms, I only consider the average, it seems to happen that I try to trigger C3/C4 when there is just something copied and some bm active ?!? I don't think that this is perfect behaviour: if the system is idle, and there is _currently_ bus master activity, the CPU should be put into C1 or C2 type sleep. If you select C3 and actually enter it, you're risking DMA issues, AFAICS. What kinds of DMA issues? Waiting 32msec or so is only heuristic; it can go wrong any time. It would be really bad if it corrupted data or something like that. loop() a) bus mastering activity is going on at the very moment b) the CPU is entering C3 c) the CPU is woken out of C3 because of bus mastering activity the repeated delay between b) and c) might be problematic, as can be seen by the comment in processor_idle.c: * TBD: A better policy might be to fallback to the demotion * state (use it for this quantum only) istead of * demoting -- and rely on duration as our sole demotion * qualification. This may, however, introduce DMA * issues (e.g. floppy DMA transfer overrun/underrun). */ I'm not so worried about floppy DMA but about the ipw2x00 issues here. Dominik - 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: USB / PCMCIA not working/panic on AVERATEC 3500
Hi, Socket status: 0720 This looks strange. Socket status 0720 can't really be true -- I assume there is a problem with the resource allocation. Can you send me /proc/iomem /proc/ioport please? Thanks, Dominik - 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.12 vs. /sbin/cardmgr
Hi, On Sun, Jul 10, 2005 at 03:37:22PM -0500, Bob Tracy wrote: Dominik Brodowski wrote: On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote: (/sbin/cardmgr chewing up lots of CPU cycles with 2.6.12 kernel) Please post the output of lspci and lsmod as I'd like to know which kind of PCMCIA bridge is in your notebook. OK, it's a plain TI1225. Could you try whether the bug is still existent in 2.6.13-rc3, please? Thanks, Dominik - 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.13-rc3][PCMCIA] - iounmap: bad address f1d62000
Hi, Could you send me the output of /proc/iomem on both a working kernel and on 2.6.13-rc3-APM, please? Thanks, Dominik - 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: PCMCIA_SOCKET unable to apply filter after Ram Upgrade
Hi, On Sat, Jul 16, 2005 at 05:14:36PM +0200, Frederic Gaus wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi folks! I've recently done a RAM upgrade on my IBM Thinkpad R40 (2722). 1. Ram-Chip: pc2100 cl 2.5 512 MB 2. Ram-Chip: pc2700 cl 2.5 1024 MB When booting with only one Chip inside, everything works perfecly. (Never mind in which slot). But when using both, I get this error message every few seconds: kernel: cs: pcmcia_socket0: unable to apply power. Changing the slots does't fix the problem. High Memory Support is enabled. Who can help? Or do you need more information? Probably a BIOS bug which we need to work around. Please send me the output of dmesg and /proc/iomem with 1GB RAM. Dominik - 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.12 vs. /sbin/cardmgr
Hi! On Sat, Jul 16, 2005 at 11:36:45AM -0500, Bob Tracy wrote: rct wrote: Dominik Brodowski wrote: On Sun, Jul 10, 2005 at 03:37:22PM -0500, Bob Tracy wrote: Dominik Brodowski wrote: On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote: (/sbin/cardmgr chewing up lots of CPU cycles with 2.6.12 kernel) Please post the output of lspci and lsmod as I'd like to know which kind of PCMCIA bridge is in your notebook. OK, it's a plain TI1225. Could you try whether the bug is still existent in 2.6.13-rc3, please? 2.6.13-rc3 works fine here. The cardmgr process is no longer chewing up lots of CPU time, and otherwise seems to be working correctly. Thanks! I spoke too soon :-(. The first boot on 2.6.13-rc3 was fine. Every boot since then has reflected no change relative to the 2.6.12 behavior. The cardmgr process racks up CPU time almost as fast as time elapses: it's at the top of the top list. Can you send me a dmesg of 2.6.13-rc3, please? Thanks, Dominik - 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.13-rc3][PCMCIA] - iounmap: bad address f1d62000
On Sat, Jul 16, 2005 at 04:21:44PM +0100, Russell King wrote:
On Sat, Jul 16, 2005 at 05:12:58PM +0200, Dominik Brodowski wrote:
Could you send me the output of /proc/iomem on both a working kernel and on
2.6.13-rc3-APM, please?
Dominik, I'd suggest looking elsewhere. The memory regions must be
free to be able to call into readable(), and therefore pccard_validate_cis().
What seems to be happening is that s-ops-set_mem_map in set_cis_map
is returning an error, causing it to free the ioremapped region
multiple times. Maybe the card has an invalid CIS causing an out
of range card_start to be requested?
Could you check whether this patch helps, please?
Index: 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c
===
--- 2.6.13-rc3-git2.orig/drivers/pcmcia/cistpl.c
+++ 2.6.13-rc3-git2/drivers/pcmcia/cistpl.c
@@ -88,31 +88,38 @@ EXPORT_SYMBOL(release_cis_mem);
static void __iomem *
set_cis_map(struct pcmcia_socket *s, unsigned int card_offset, unsigned int
flags)
{
-pccard_mem_map *mem = s-cis_mem;
-int ret;
+ pccard_mem_map *mem = s-cis_mem;
+ int ret;
-if (!(s-features SS_CAP_STATIC_MAP) mem-res == NULL) {
- mem-res = pcmcia_find_mem_region(0, s-map_size, s-map_size, 0, s);
- if (mem-res == NULL) {
- printk(KERN_NOTICE cs: unable to map card memory!\n);
- return NULL;
- }
- s-cis_virt = ioremap(mem-res-start, s-map_size);
-}
-mem-card_start = card_offset;
-mem-flags = flags;
-ret = s-ops-set_mem_map(s, mem);
-if (ret) {
- iounmap(s-cis_virt);
- return NULL;
-}
-
-if (s-features SS_CAP_STATIC_MAP) {
- if (s-cis_virt)
- iounmap(s-cis_virt);
- s-cis_virt = ioremap(mem-static_start, s-map_size);
-}
-return s-cis_virt;
+ if (!(s-features SS_CAP_STATIC_MAP) (mem-res == NULL)) {
+ mem-res = pcmcia_find_mem_region(0, s-map_size, s-map_size,
0, s);
+ if (mem-res == NULL) {
+ printk(KERN_NOTICE cs: unable to map card memory!\n);
+ return NULL;
+ }
+ s-cis_virt = NULL;
+ }
+
+ if (!(s-features SS_CAP_STATIC_MAP) (!s-cis_virt))
+ s-cis_virt = ioremap(mem-res-start, s-map_size);
+
+ mem-card_start = card_offset;
+ mem-flags = flags;
+
+ ret = s-ops-set_mem_map(s, mem);
+ if (ret) {
+ iounmap(s-cis_virt);
+ s-cis_virt = NULL;
+ return NULL;
+ }
+
+ if (s-features SS_CAP_STATIC_MAP) {
+ if (s-cis_virt)
+ iounmap(s-cis_virt);
+ s-cis_virt = ioremap(mem-static_start, s-map_size);
+ }
+
+ return s-cis_virt;
}
/*==
-
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/
[PATCH] pcibios_bus_to_resource for parisc [Was: Re: [PATCH 8/8] pci and yenta: pcibios_bus_to_resource]
On Mon, Jul 18, 2005 at 01:42:16PM -0600, Grant Grundler wrote:
On Tue, Jul 12, 2005 at 12:21:38AM +0200, Dominik Brodowski wrote:
In yenta_socket, we default to using the resource setting of the CardBus
bridge. However, this is a PCI-bus-centric view of resources and thus
needs to be converted to generic resources first. Therefore, add a call
to pcibios_bus_to_resource() call in between. This function is a mere
wrapper on x86 and friends, however on some others it already exists, is
added in this patch (alpha, arm, ppc, ppc64) or still needs to be
provided (parisc -- where is its pcibios_resource_to_bus() ?).
in arch/parisc/kernel/pci.c?
At least, it seems to be present in the 2.6.13-rc1 tree
on cvs.parisc-linux.org tree.
Oh, yes, I seem to have missed it. Sorry. Does this patch look good?
Add pcibios_bus_to_resource for parisc.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
Index: 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
===
--- 2.6.13-rc3-git2.orig/arch/parisc/kernel/pci.c
+++ 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
@@ -255,8 +255,26 @@ void __devinit pcibios_resource_to_bus(s
pcibios_link_hba_resources(hba-lmmio_space, bus-resource[1]);
}
+void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region)
+{
+ struct pci_bus *bus = dev-bus;
+ struct pci_hba_data *hba = HBA_DATA(bus-bridge-platform_data);
+
+ if (res-flags IORESOURCE_MEM) {
+ res-start = PCI_HOST_ADDR(hba, region-start);
+ res-end = PCI_HOST_ADDR(hba, region-end);
+ }
+
+ if (res-flags IORESOURCE_IO) {
+ res-start = region-start;
+ res-end = region-end;
+ }
+}
+
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resource);
#endif
/*
-
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: [PATCH 2.6.13-rc3] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT
Hi,
When a driver calls pcmcia_request_irq with IRQ_HANDLE_PRESENT unset, it looks
for an open IRQ by request_irq()ing with a dummy handler and NULL dev_info.
free_irq uses dev_info as a key for identifying the handler to free among
those
sharing an IRQ, so request_irq returns -EINVAL if dev_info is NULL and the IRQ
may be shared. That unknown error code is the -EINVAL.
It looks like only pcnet_cs and axnet_cs are affected. Most other drivers let
pcmcia_request_irq install their interrupt handlers. sym53c500_cs requests
its
IRQ manually, but it cannot share an IRQ.
The appended patch changes pcmcia_request_irq to pass an arbitrary, unique,
non-NULL dev_info with the dummy handler.
Thanks for the excellent debugging. Your patch seems to work, however it
might be better to do just this:
Index: 2.6.13-rc3-git2/drivers/pcmcia/pcmcia_resource.c
===
--- 2.6.13-rc3-git2.orig/drivers/pcmcia/pcmcia_resource.c
+++ 2.6.13-rc3-git2/drivers/pcmcia/pcmcia_resource.c
@@ -800,7 +800,7 @@ int pcmcia_request_irq(struct pcmcia_dev
} else {
int try;
u32 mask = s-irq_mask;
- void *data = NULL;
+ void *data = test_action;
for (try = 0; try 64; try++) {
irq = try % 32;
Thanks,
Dominik
-
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: [PATCH 2.6.13-rc3] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT
On Sun, Jul 24, 2005 at 12:40:40PM +0100, Russell King wrote: On Sat, Jul 23, 2005 at 10:11:13PM +0200, Dominik Brodowski wrote: Thanks for the excellent debugging. Your patch seems to work, however it might be better to do just this: This can be racy if two drivers are simultaneously trying to request an IRQ. 'data' must be unique to different threads if they are to avoid interfering with each other. As it's enough to keep PCMCIA functions apart (there can't be two drivers registering with the same PCMCIA function at the same moment), I'll use that now. void *data = p_dev-dev.driver; /* something unique to this device */ Thanks, Dominik - 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: [PATCH] Updated: Dynamic Tick version 050408-1 - C-state measures
Hi, On Wed, Apr 20, 2005 at 02:08:46PM +0200, Pavel Machek wrote: Like ipw2x00 looses packets if this happens too often? See PCI latency error if C3 enabled on http://ipw2100.sf.net -- it causes network instability, frequent firmware restarts. Dominik - 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: speedstep-centrino on dothan
Hi, On Wed, Jul 06, 2005 at 11:22:02AM +0200, [EMAIL PROTECTED] wrote: Currently, the speedstep-centrino support has built-in frequency/voltage pairs only for Banias CPUs. For Dothan CPUs, these tables are read from BIOS ACPI. But ACPI encoding may not be available or not reliable, so why shouldn't we provide built-in tables for Dothan CPUs, too? Intel has released this datasheet: http://www.intel.com/design/mobile/datashts/302189.htm with frequency/voltage pairs for every version of Dothan CPUs. However, it is not known which one of VID#A, VID#B, VID#C or VID#D is to be used on a specific system. Dominik - 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: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote: Just a latest question: can be p4-clockmod used together with speedstep-centrino? If not, would it make any sense to patch speedstep-centrino to use this feature too? I'm a little confused. How is this different from the ACPI CPU throttling states (/proc/acpi/processor/CPUn/limit to set, throttling to see all T-states available)? T-states _tend_ to be utilized using chipset logic, while p4-clockmod is done in-CPU. On my 1.5-year-old Pentium-M, frequency scaling and T-states are different beasties, and act entirely differently. I'm currently in the process of rewriting my governor's brain to deal with the two more intelligently. In your case, I would care about throttling. In very most cases it actually increases energy consumption, as the state being entered is technically the same to ACPI C2 (IIRC), so it is only forced idling and only useful if forced idling is needed to not need active cooling. Dominik - 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: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
On Thu, Jul 07, 2005 at 10:22:25PM +0200, [EMAIL PROTECTED] wrote: This hasn't been seen to save any power whatsoever that I've seen. It drops down power rating by 1500-1800mW on my Toshiba Satellite A50 while idling at 400MHz. Do you use ACPI-based idling? If so, in which state is the CPU in (cat /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else you wouldn't need the table-based approach) or that the ACPI-based idling is broken on your notebook; as then the Linux idle handler only makes use of hlt (IIRC), that is ACPI C1, while throttling forces ACPI C2 (again IIRC). Dominik - 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: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
On Thu, Jul 07, 2005 at 04:34:14PM -0500, Joseph Pingenot wrote: From Dominik Brodowski on Thursday, 07 July, 2005: On Thu, Jul 07, 2005 at 03:51:17PM -0500, Joseph Pingenot wrote: Just a latest question: can be p4-clockmod used together with speedstep-centrino? If not, would it make any sense to patch speedstep-centrino to use this feature too? I'm a little confused. How is this different from the ACPI CPU throttling states (/proc/acpi/processor/CPUn/limit to set, throttling to see all T-states available)? T-states _tend_ to be utilized using chipset logic, while p4-clockmod is done in-CPU. On my 1.5-year-old Pentium-M, frequency scaling and T-states are different beasties, and act entirely differently. I'm currently in the process of rewriting my governor's brain to deal with the two more intelligently. In your case, I would care about throttling. In very most cases it actually increases energy consumption, as the state being entered is technically the same to ACPI C2 (IIRC), so it is only forced idling and only useful if forced idling is needed to not need active cooling. Why would this cause more energy consumption? Let's say a specific computing task needs 1s to run at 100% CPU load. The CPU consumes 22 W at normal operation, and 7.3 W when in ACPI C2 state which is technically equivalent to throttling. [note: these are _real_ values from a real datasheet for a real CPU you see in common usage] If you're at 0% CPU throttling rate, you need 22 Ws for this computing task, if you're at 25%24 Ws, at 50%29 Ws, and at 75%that is 44 Ws for this computing task. So for any sepcific computing task the energy consumption increases largely. But what if the system idle otherwise? If the CPU is put into an idle state the other time (e.g. there is no other computing task for the CPU to do in a four-second span), it depends on the idle state being used: if it is C2, these four seconds mean 44Ws of energy being used; if it is C3, the CPU only needs 5.1Ws, so at 0% CPU throttling you get 37 Ws; if it is C4, the CPU only needs 0.55Ws, so you only get 24 Ws which is much less than the 44Ws you have at 75% throttling. Please note that the weak spot in this calculation is the idle state the CPU is forced to when doing idling. My investigations lead to the assumption that it is the Stop Grant state on CPUs manufactored by Intel, which is most often described by the ACPI C2 state (Stop-Grant state), while C3 is Deep Sleep State or Sleep State, and C4 is Deeper Sleep State. Dominik - 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: enhanced intel speedstep feature was Re: speedstep-centrino on dothan
On Thu, Jul 07, 2005 at 11:22:38PM +0200, [EMAIL PROTECTED] wrote: On Thu, 7 Jul 2005 23:10:33 +0200 Dominik Brodowski [EMAIL PROTECTED] wrote: Do you use ACPI-based idling? If so, in which state is the CPU in (cat /proc/acpi/processor/*/power ? I suspect that you do not use ACPI (else you wouldn't need the table-based approach) or that the ACPI-based idling is broken on your notebook; as then the Linux idle handler only makes use of hlt (IIRC), that is ACPI C1, while throttling forces ACPI C2 (again IIRC). For idling, I didn't mean 'real idling', but instead just 'doing nothing' in ACPI C1 state, that's simply a CPU usage 1%. Sorry for being so lame =) That's exactly the idling I meant. So if it is only ACPI C1, then throttling makes some sense. It makes more sense, though, to get ACPI C2, C3 and possibly C4 to work :) Dominik - 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: speedstep-centrino on dothan
On Thu, Jul 07, 2005 at 11:59:28PM +0200, [EMAIL PROTECTED] wrote: read from ACPI tables, while still keeping them available. You're only keeping some of them available, as you overwrite one such setting. Alternatively you can increase p.state_count by one early enough. index = (((frequency)/100) 8) | ((voltage - 700) / 16); printf (%u\n, index); printf (0x%x\n, index); is better want 500MHz at 940mV, you could add: centrino_model[cpu]-op_points[p.state_count - 2].index = 0x1295; centrino_model[cpu]-op_points[p.state_count - 2].index = 50; .frequency p.states[p.state_count - 2].core_frequency = 500; Dominik - 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/
PCMCIA stack reduction patch [Was: Re: Realtime Preemption, 2.6.12, Beginners Guide?]
Hi, On Sat, Jul 09, 2005 at 03:26:57PM +0200, Ingo Molnar wrote: (gdb) (gdb) # c02a0a26, stack size: 416 bytes # (gdb) (gdb) 0xc02a0a26 is in pcmcia_device_query (drivers/pcmcia/ds.c:436). this patch reduces the stack footprint of pcmcia_device_query() from 416 bytes to 36 bytes. (patch only build-tested) Applied and tested, but without the final hunk. @@ -856,7 +868,9 @@ static int bind_request(struct pcmcia_bu rescan: p_dev-cardmgr = p_drv; - pcmcia_device_query(p_dev); + ret = pcmcia_device_query(p_dev); + if (ret) + goto err_put_module; /* * Prevent this racing with a card insertion. We don't check the return value here for a reason. Thanks, Dominik - 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.12 vs. /sbin/cardmgr
Hi, On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote: I've got a Mandrake 10.0 system with a 2.6.12 kernel presently. Somewhere between 2.6.11 and 2.6.12, /sbin/cardmgr from the pcmcia-cs-3.2.5-3mdk package decided it needs to consume incredible amounts of CPU time when invoked the first time following a boot. You can definitely notice the load on the system. Stopping cardmgr requires a kill -9: softer kills are ignored. Restarting cardmgr produces the following output: cardmgr[3731]: watching 2 sockets cardmgr[3731]: could not adjust resource: IO ports 0xc00-0xcff: Device or resource busy cardmgr[3731]: could not adjust resource: IO ports 0x100-0x4ff: Device or resource busy cardmgr[3731]: could not adjust resource: memory 0xc-0xf: Input/output error cardmgr[3731]: could not adjust resource: memory 0x6000-0x60ff: Input/output error cardmgr[3731]: could not adjust resource: memory 0xa000-0xa0ff: Input/output error cardmgr[3731]: could not adjust resource: IO ports 0x1000-0x1fff: Device or resource busy cardmgr[3731]: could not adjust resource: IO ports 0xa00-0xaff: Device or resource busy But at least it doesn't seem to be running around in tight circles at this point :-). System is a Dell Latitude CPxJ notebook that continues to work fine with 2.6.11 and older kernels. Any idea what changed between 2.6.11 and 2.6.12 that might be causing this problem? I can probably provide more info on request. Please post the output of lspci and lsmod as I'd like to know which kind of PCMCIA bridge is in your notebook. Dominik - 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/
[PATCH 8/8] pci and yenta: pcibios_bus_to_resource
In yenta_socket, we default to using the resource setting of the CardBus
bridge. However, this is a PCI-bus-centric view of resources and thus
needs to be converted to generic resources first. Therefore, add a call
to pcibios_bus_to_resource() call in between. This function is a mere
wrapper on x86 and friends, however on some others it already exists, is
added in this patch (alpha, arm, ppc, ppc64) or still needs to be
provided (parisc -- where is its pcibios_resource_to_bus() ?).
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
arch/alpha/kernel/pci.c | 16
arch/arm/kernel/bios32.c | 17 +
arch/ppc/kernel/pci.c | 15 +++
arch/ppc64/kernel/pci.c | 20
drivers/pcmcia/yenta_socket.c | 15 ++-
include/asm-alpha/pci.h |3 +++
include/asm-arm/pci.h |4
include/asm-generic/pci.h |8
include/asm-parisc/pci.h |4
include/asm-ppc/pci.h |4
include/asm-ppc64/pci.h |4
11 files changed, 101 insertions(+), 9 deletions(-)
Index: 2.6.13-rc2-git3/include/asm-generic/pci.h
===
--- 2.6.13-rc2-git3.orig/include/asm-generic/pci.h
+++ 2.6.13-rc2-git3/include/asm-generic/pci.h
@@ -22,6 +22,14 @@ pcibios_resource_to_bus(struct pci_dev *
region-end = res-end;
}
+static inline void
+pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region)
+{
+ res-start = region-start;
+ res-end = region-end;
+}
+
#define pcibios_scan_all_fns(a, b) 0
#ifndef HAVE_ARCH_PCI_GET_LEGACY_IDE_IRQ
Index: 2.6.13-rc2-git3/drivers/pcmcia/yenta_socket.c
===
--- 2.6.13-rc2-git3.orig/drivers/pcmcia/yenta_socket.c
+++ 2.6.13-rc2-git3/drivers/pcmcia/yenta_socket.c
@@ -605,9 +605,8 @@ static int yenta_search_res(struct yenta
static int yenta_allocate_res(struct yenta_socket *socket, int nr, unsigned
type, int addr_start, int addr_end)
{
- struct pci_bus *bus;
struct resource *root, *res;
- u32 start, end;
+ struct pci_bus_region region;
unsigned mask;
res = socket-dev-resource + PCI_BRIDGE_RESOURCES + nr;
@@ -620,15 +619,13 @@ static int yenta_allocate_res(struct yen
if (type IORESOURCE_IO)
mask = ~3;
- bus = socket-dev-subordinate;
- res-name = bus-name;
+ res-name = socket-dev-subordinate-name;
res-flags = type;
- start = config_readl(socket, addr_start) mask;
- end = config_readl(socket, addr_end) | ~mask;
- if (start end start !override_bios) {
- res-start = start;
- res-end = end;
+ region.start = config_readl(socket, addr_start) mask;
+ region.end = config_readl(socket, addr_end) | ~mask;
+ if (region.start region.end region.start !override_bios) {
+ pcibios_bus_to_resource(socket-dev, res, region);
root = pci_find_parent_resource(socket-dev, res);
if (root (request_resource(root, res) == 0))
return 0;
Index: 2.6.13-rc2-git3/arch/arm/kernel/bios32.c
===
--- 2.6.13-rc2-git3.orig/arch/arm/kernel/bios32.c
+++ 2.6.13-rc2-git3/arch/arm/kernel/bios32.c
@@ -447,9 +447,26 @@ pcibios_resource_to_bus(struct pci_dev *
region-end = res-end - offset;
}
+void __devinit
+pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region)
+{
+ struct pci_sys_data *root = dev-sysdata;
+ unsigned long offset = 0;
+
+ if (res-flags IORESOURCE_IO)
+ offset = root-io_offset;
+ if (res-flags IORESOURCE_MEM)
+ offset = root-mem_offset;
+
+ res-start = region-start + offset;
+ res-end = region-end + offset;
+}
+
#ifdef CONFIG_HOTPLUG
EXPORT_SYMBOL(pcibios_fixup_bus);
EXPORT_SYMBOL(pcibios_resource_to_bus);
+EXPORT_SYMBOL(pcibios_bus_to_resources);
#endif
/*
Index: 2.6.13-rc2-git3/include/asm-alpha/pci.h
===
--- 2.6.13-rc2-git3.orig/include/asm-alpha/pci.h
+++ 2.6.13-rc2-git3/include/asm-alpha/pci.h
@@ -251,6 +251,9 @@ static inline int pci_get_legacy_ide_irq
extern void pcibios_resource_to_bus(struct pci_dev *, struct pci_bus_region *,
struct resource *);
+extern void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
+ struct pci_bus_region *region);
+
#define pci_domain_nr(bus) ((struct pci_controller *)(bus)-sysdata)-index
static inline int pci_proc_domain(struct pci_bus *bus)
Index: 2.6.13-rc2-git3/include/asm-arm/pci.h
Re: inconsistent kallsyms data [2.6.11-mm2]
On Sun, Mar 13, 2005 at 09:54:41AM +0100, Sam Ravnborg wrote: On Thu, Mar 10, 2005 at 12:12:22PM +, Paulo Marques wrote: Paulo Marques wrote: [...] A simple and robust way is to do the sampling on a list of symbols sorted by symbol name. This way, even if the symbol positions that are given to scripts/kallsyms change, the symbols sampled will be the same. I'll do the patch to do this and send it ASAP. Ok, here it is. Dominik can you try the attached patch and see if it solves the problem? Hi Paulo. Alexander Stohr had similar problems with down and __sched_text_start. I figured out that what was causing the troubles was the fact that the linker generated symbol __sched_text_start changed value from pass 1 to pass 2. The reason for this was the alingment used within that section. My stamp on this is attached. I never came around submitting this since I do not know what the correct number for function alignment is on different paltforms. This patch fixes it on my (x86) system. Thanks, Dominik - 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: cpufreq on-demand governor up_treshold?
On Mon, Mar 14, 2005 at 08:57:52AM +0100, Eric Piel wrote: BTW, DaveJ, Dominik, I couldn't find them in the daily-snapshot available at codemonkey.org.uk. Should I worry, or is it just due to some latency between your private trees and the public one? /me has no official position wrt cpufreq core [except userspace cpufrequtils, but I intend to hand this over to somebody else in the next few months]. Dave, as maintainer of cpufreq, has a cpufreq bitkeeper tree [http interface at http://linux-dj.bkbits.net/ ] which is exported as plain diff daily at http://www.codemonkey.org.uk/projects/cpufreq/daily-snapshots/ . This does not contain your patches yet, probably because he's still busy with other stuff. Thanks, Dominik - 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: inconsistent kallsyms data [2.6.11-mm2]
On Thu, Mar 10, 2005 at 12:12:22PM +, Paulo Marques wrote: Paulo Marques wrote: [...] A simple and robust way is to do the sampling on a list of symbols sorted by symbol name. This way, even if the symbol positions that are given to scripts/kallsyms change, the symbols sampled will be the same. I'll do the patch to do this and send it ASAP. Ok, here it is. Dominik can you try the attached patch and see if it solves the problem? It does not solve the problem: ~/local/kernel/linux-2.6.11-mm2 $ patch -p1 ~/kallpatch patching file scripts/kallsyms.c ~/local/kernel/linux-2.6.11-mm2 $ make CHK include/linux/version.h HOSTCC scripts/kallsyms make[1]: »arch/i386/kernel/asm-offsets.s« ist bereits aktualisiert. CHK include/linux/compile.h CHK usr/initramfs_list CC [M] arch/i386/kernel/cpu/cpufreq/acpi-cpufreq.o KSYM.tmp_kallsyms1.S AS .tmp_kallsyms1.o LD .tmp_vmlinux2 KSYM.tmp_kallsyms2.S AS .tmp_kallsyms2.o LD vmlinux SYSMAP System.map SYSMAP .tmp_System.map Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make: *** [vmlinux] Fehler 1 Will test the other patch floating around in just a moment. Thanks, Dominik - 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: [RFC] Changes to the driver model class code.
On Tue, Mar 15, 2005 at 09:08:34AM -0800, Greg KH wrote: Then I moved the USB host controller code to use this new interface. That was a bit more complex as it used the struct class and struct class_device code directly. As you can see by the patch, the result is pretty much identical, and actually a bit smaller in the end. So I'll be slowly converting the kernel over to using this new interface, and when finished, I can get rid of the old class apis (or actually, just make them static) so that no one can implement them improperly again... Comments? The old class api _forced_ you to think of reference counting of dynamically allocated objects, while it gets easier to get reference counting wrong using this simple/new interface: while struct class will always have fine reference counting, the parent struct [with struct class no longer being embedded] needs to be thought of individually; and the reference count cannot be shared any longer. Also, it seems to me that you view the class subsystem to be too closely related to /dev entries -- and for these /dev entries class_simple was introduced, IIRC. However, /dev is not the reason the class subsystem was introduced for -- instead, it describes _types_ of devices which want to share (userspace and in-kernel) interfaces. For example pcmcia sockets which can reside on different buses, but can be handled (mostly) the same way by kernel- and userspace. For example, temperature sensors could be exported using /sys/class/temp_sensors/... -- then userspace wouldn't need to know whether the temperature was determined using an ACPI BIOS call or by accessing an i2c device. Such abstractions, and other kernel code whcih uses these abstractions (a.k.a. class interfaces) are a great feature to have, and one too less used by now. Dominik - 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: [RFC] Changes to the driver model class code.
On Tue, Mar 15, 2005 at 11:51:21AM -0800, Greg KH wrote: Also, it seems to me that you view the class subsystem to be too closely related to /dev entries -- and for these /dev entries class_simple was introduced, IIRC. However, /dev is not the reason the class subsystem was introduced for -- instead, it describes _types_ of devices which want to share (userspace and in-kernel) interfaces. I agree, I know it isn't directly related to /dev entries, but that _is_ the most common usage of it, so I can't ignore it :) I did not say ignore. Having the new interface available (patches 1-3) seems to be a sensible thing to do. Removing the so-called old api (patches 4-x) is a different topic, though. Anyway, it's very simple to convert over to using the new functions, and still have all of your sysfs and reference counting functionality. See the USB patch that I posted in this series as an example of how to do this. Just use a kref and a pointer to the class_device. You have all of the previous functionality that you needed before right there. However, you need to do it in _addition_ -- you don't get it for free if using struct class. Which means prgrammers need to think of two things instead of one. And that's bad(TM). Also, the lack of proper reference counting in several parts of the kernel is proof enough that there's need to encourage reference counting. And that's something the class subsystem did and does by providing easy embedded reference counting, by warning on missing !release functions etc. class interfaces are not going away, there's a good need for them like you have pointed out. I'm not expecting to just delete those api functions tomorrow, but slowly phase out the use of them over time, and hopefully, eventually get rid of them. I think that with my USB host controller patch, I've proved that they are not as needed as you might think they were. Indeed, such _workarounds_ are possible. A patch which converts pcmcia to this new infrastructure would be quite trivial to write. However: I think we should NOT do it. As it is a workaround to the more elegant solution the old class API alllowed for. It's easy to make a complex, powerful, all-singing-all-dancing api. That's what we have today. It's hard to make such an api easy to use, that's what we need to realize and start to fix. This is the first of such steps to try to achieve this. Math is hard, so let's go shopping. The I want a /dev-entry-api may get easier with your patches 1-3. With your patch 4 there is no improvement in this area, however the I want sane device-related reference counting-api will be much more difficult to get right. Thanks, Dominik - 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: [linux-usb-devel] Re: [RFC] Changes to the driver model class code.
On Tue, Mar 15, 2005 at 01:14:40PM -0800, David Brownell wrote: That pre-driver model stuff went away in maybe 2.6.5 or so, I forget just when. If you think those changes can easily be reversed, I suggest you think again ... they enabled a LOT of likewise-overdue cleanups. ... converting to the driver model has been a win at every step of the way. It's gone both ways; the driver core has changed to work better with USB too. Exactly my point: the driver code forces/encourages you to write better code. With proper reference counting. And reverting this by making class_simple default, and possibly doing a similar transition for struct device and struct device_driver means that we lose this encouragement. and we lose this win-win situation. Thanks, Dominik - 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: [RFC] Changes to the driver model class code.
On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote: So this means every device will have yet another reference count, and you need to be aware of _each_ lifetime to write correct code. And the _reference counting_ is the hard thing to get right, so we should make _that_ easier. The existing class API was a step towards this direction, and with the changes you're suggesting here we'd do two jumps backwards. You are correct, it was a step forward in this direction. But we now have a kref to handle the reference counting for the device, which make things a whole lot easier than ever before. Is it really easier if you have to be aware of _both_ the class reference possibly having reached zero yet and the kref device reference possibly having reached zero yet? Using your approach, you need to take _two_ lifetimes into account instead of one. Think of class device attributes being opened / still being accessed when kref device reference reaching zero... you need to check for that in code now, AFAICS, while you could rely on we still have a reference to the _device_ in historic class device attribute access paths. But the both of you are correct, there is a real need for the class code to support trees of devices that are presented to userspace (which is what the class code is for). I'm not taking that away, just trying to make the interface to that code simpler. The interface may get simpler, but we lose the advantages. And I prefer a interface which reduces the chances of doing things wrongly; and at least the existing warnings on empty release functions force you to _think_ about what you do. I'm also not saying that I'm going to go off and delete those functions from the kernel today, or tomorrow. ... Anyway, don't worry, the code isn't going away anytime soon, That's totally besides the point. If the decision was made to indeed do this transition, I'd be all for doing this fast. If the old code was gone within two weeks, I wouldn't care because of the short period, but because of the functionality being lost: I will not be removing any functionality, don't worry :) the functionality of the device core to teach, encourage, and forcing to think of reference counting is being lost by this approach. Independent of the question whether the transition will take two weeks or two years. It will not make the reference counting logic easier to get wrong, or easier to get right. It totally takes it away from the user, and makes them implement it themselves if they so wish (like the USB HCD patch does.). Keeping the chance to do the new/class_simple way is a good thing -- so that anybody who _knows_ _exactly_ what he does can shoot himself in his foot^W^W^W^W^W do what is best for the affected code. we just need to make it easier to use. Any suggestions that any of you have to make this that way (as you are the ones who had to use it to start with) would be greatly appreciated. drivers/base/class_simple.c: printk(are you really sure you don't want not to have reference counting for free by using struct class instead of struct class_simple *?\n); :) Thanks, Dominik - 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/
[PATCH 1/2] PCI-PCI transparent bridge handling improvements (pci core)
Transparent PCI-PCI bridges are currently ignored by the resource
management code in the PCI core. This means devices behind the bridge are
handled as if there was no bridge.
However, it seems more suitable -- and it seems to allow for proper
prefetch-type memory handling, too -- to handle a transparent PCI-PCI bridge
like any other PCI-PCI bridge, and to only break out of the limits set by
the bridge windows if the resource allocation code determines it needs to
do s.
The tricky part is in pci_find_parent_resource(). There are two types of
functions calling it: some functions already know the exact resource for
which they want to find the parent in order to properly insert it into the
resource database. This can be handled easily -- if the resource is inside
the bridge window, this is returned; if it isn't, the bridge's parent
resource is returned.
However, two callers (yenta_socket and i2o) intend something different: they
call pci_find_parent_resource() with an empty resource and want to find out
the biggest valid resource of the proper type in order to analyze it and
adapt its own hunger for resources to it. To keep this behaviour
backwards-compatible, we always need to not limit it to the bridge window
resources, but get back to the parent bus.
This patch is a modified and (hopefully) improved derivation of Linus'
pcmcia-bridge-resource-management-fix.patch included in 2.6.11-rc4-mm1.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
Index: 2.6.11++/drivers/pci/bus.c
===
--- 2.6.11++.orig/drivers/pci/bus.c 2005-03-17 00:39:00.0 +0100
+++ 2.6.11++/drivers/pci/bus.c 2005-03-17 00:39:24.0 +0100
@@ -18,22 +18,12 @@
#include pci.h
/**
- * pci_bus_alloc_resource - allocate a resource from a parent bus
- * @bus: PCI bus
- * @res: resource to allocate
- * @size: size of resource to allocate
- * @align: alignment of resource to allocate
- * @min: minimum /proc/iomem address to allocate
- * @type_mask: IORESOURCE_* type flags
- * @alignf: resource alignment function
- * @alignf_data: data argument for resource alignment function
+ * pci_one_bus_alloc_resource - allocate a resource from one specific bus
*
- * Given the PCI bus a device resides on, the size, minimum address,
- * alignment and type, try to find an acceptable resource allocation
- * for a specific device resource.
+ * Always use pci_bus_alloc_resource() described below.
*/
-int
-pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
+static int
+pci_one_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
unsigned long size, unsigned long align, unsigned long min,
unsigned int type_mask,
void (*alignf)(void *, struct resource *,
@@ -69,6 +59,48 @@
}
/**
+ * pci_bus_alloc_resource - allocate a resource from a parent bus
+ * @bus: PCI bus
+ * @res: resource to allocate
+ * @size: size of resource to allocate
+ * @align: alignment of resource to allocate
+ * @min: minimum /proc/iomem address to allocate
+ * @type_mask: IORESOURCE_* type flags
+ * @alignf: resource alignment function
+ * @alignf_data: data argument for resource alignment function
+ *
+ * Given the PCI bus a device resides on, the size, minimum address,
+ * alignment and type, try to find an acceptable resource allocation
+ * for a specific device resource.
+ */
+int
+pci_bus_alloc_resource(struct pci_bus *bus, struct resource *res,
+ unsigned long size, unsigned long align, unsigned long min,
+ unsigned int type_mask,
+ void (*alignf)(void *, struct resource *,
+ unsigned long, unsigned long),
+ void *alignf_data)
+{
+ int ret = pci_one_bus_alloc_resource(bus, res, size, align, min,
+ type_mask, alignf, alignf_data);
+
+ /*
+* If allocation from the resources available to this bus failed,
+* and there is a transparent parent PCI-PCI bridge, we can check
+* the resources of the parent bus as well
+*/
+ while (ret bus-self bus-self-transparent) {
+ bus = bus-self-bus;
+ if (!bus)
+ return ret;
+ ret = pci_one_bus_alloc_resource(bus, res, size, align, min,
+ type_mask, alignf, alignf_data);
+ }
+ return ret;
+}
+
+
+/**
* add a single device
* @dev: device to add
*
Index: 2.6.11++/drivers/pci/pci.c
===
--- 2.6.11++.orig/drivers/pci/pci.c 2005-03-17 00:39:00.0 +0100
+++ 2.6.11++/drivers/pci/pci.c 2005-03-17 01:12:18.0 +0100
@@ -195,18 +195,13 @@
}
/**
- * pci_find_parent_resource - return resource region of parent bus of given
region
- * @dev: PCI device structure contains resources to be searched
- * @res: child resource record for which parent is sought
+ * pci_bus_find_parent_resource
[PATCH 2/2] PCI-PCI transparent bridge handling improvements (yenta_socket)
As a follow-up, we can make yenta_socket try harder to limit itself to the
parent bridge windows. This is done by lowering the
PCIBIOS_MIN_CARDBUS_IO and by updating yenta_allocate_res(). It now tries at
first to get resources within the bridge windows, and if they are large
enough (=BRIDGE_{IO,MEM}_ACC), these are used. If no or only too small
resources were found, it falls back to the resources behind the parent PCI
bridge if this is transparent. Using this patch may result in such funny
/proc/ioports as:
2800-28ff : PCI CardBus #07
3000-3fff : PCI Bus #02
3000-303f : :02:08.0
3000-303f : e100
3400-34ff : PCI CardBus #03
3800-38ff : PCI CardBus #03
3c00-3cff : PCI CardBus #07
There weren't enough properly aligned ports available inside PCI Bus #02 to
stuff all four (2x2) IO windows into it, so one was taken outside the
transparent PCI bridge ioport window.
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
Index: 2.6.11++/drivers/pcmcia/yenta_socket.c
===
--- 2.6.11++.orig/drivers/pcmcia/yenta_socket.c 2005-03-17 23:13:58.0
+0100
+++ 2.6.11++/drivers/pcmcia/yenta_socket.c 2005-03-17 23:40:38.0
+0100
@@ -518,19 +518,23 @@
* Use an adaptive allocation for the memory resource,
* sometimes the memory behind pci bridges is limited:
* 1/8 of the size of the io window of the parent.
- * max 4 MB, min 16 kB.
+ * max 4 MB, min 16 kB. We try very hard to not get
+ * below the ACC values, though.
*/
#define BRIDGE_MEM_MAX 4*1024*1024
+#define BRIDGE_MEM_ACC 128*1024
#define BRIDGE_MEM_MIN 16*1024
#define BRIDGE_IO_MAX 256
+#define BRIDGE_IO_ACC 256
#define BRIDGE_IO_MIN 32
#ifndef PCIBIOS_MIN_CARDBUS_IO
#define PCIBIOS_MIN_CARDBUS_IO PCIBIOS_MIN_IO
#endif
-static void yenta_allocate_res(struct yenta_socket *socket, int nr, unsigned
type)
+static int yenta_try_allocate_res(struct yenta_socket *socket, int nr,
+ unsigned int type, unsigned int run)
{
struct pci_bus *bus;
struct resource *root, *res;
@@ -550,11 +554,11 @@
res-name = bus-name;
res-flags = type;
res-start = 0;
- res-end = 0;
+ res-end = run;
root = pci_find_parent_resource(socket-dev, res);
if (!root)
- return;
+ return -ENODEV;
start = config_readl(socket, offset) mask;
end = config_readl(socket, offset+4) | ~mask;
@@ -562,7 +566,8 @@
res-start = start;
res-end = end;
if (request_resource(root, res) == 0)
- return;
+ return 0;
+
printk(KERN_INFO yenta %s: Preassigned resource %d busy,
reconfiguring...\n,
pci_name(socket-dev), nr);
res-start = res-end = 0;
@@ -571,12 +576,12 @@
if (type IORESOURCE_IO) {
align = 1024;
size = BRIDGE_IO_MAX;
- min = BRIDGE_IO_MIN;
+ min = run ? BRIDGE_IO_ACC : BRIDGE_IO_MIN;
start = PCIBIOS_MIN_CARDBUS_IO;
end = ~0U;
} else {
unsigned long avail = root-end - root-start;
- int i;
+ u32 i;
size = BRIDGE_MEM_MAX;
if (size avail/8) {
size=(avail+1)/8;
@@ -586,26 +591,36 @@
i++;
size = 1 i;
}
- if (size BRIDGE_MEM_MIN)
- size = BRIDGE_MEM_MIN;
+ i = run ? BRIDGE_MEM_ACC : BRIDGE_MEM_MIN;
+ if (size i)
+ size = i;
min = BRIDGE_MEM_MIN;
align = size;
start = PCIBIOS_MIN_MEM;
end = ~0U;
}
-
+
do {
if (allocate_resource(root, res, size, start, end, align, NULL,
NULL)==0) {
config_writel(socket, offset, res-start);
config_writel(socket, offset+4, res-end);
- return;
+ return 0;
}
size = size/2;
align = size;
} while (size = min);
+
+ return -ENODEV;
+}
+
+static void yenta_allocate_res(struct yenta_socket *socket, int nr, unsigned
type)
+{
+ if (!(yenta_try_allocate_res(socket, nr, type, 1)) ||
+ !(yenta_try_allocate_res(socket, nr, type, 0)))
+ return;
+
printk(KERN_INFO yenta %s: no resource of type %x available, trying to
continue...\n,
pci_name(socket-dev), type);
- res-start = res-end = 0;
}
/*
@@ -616,7 +631,7 @@
yenta_allocate_res(socket, 0, IORESOURCE_MEM|IORESOURCE_PREFETCH);
yenta_allocate_res(socket, 1, IORESOURCE_MEM);
yenta_allocate_res(socket, 2, IORESOURCE_IO
[PATCH 1/1] pcmcia: select crc32 in Kconfig for PCMCIA [Was: Re: pcmcia compile problems in 2.6.11-mm4 and above]
On Mon, Mar 21, 2005 at 04:01:43PM +0100, Norbert Preining wrote: HI Andrew! Compiling 2.6.12-rc1-mm1 with the attached config gives me an error while compiling pcmcia (I made a make oldconfig) drivers/built-in.o(.text+0xaf2a2): In function `pcmcia_check_driver': : undefined reference to `crc32_le' drivers/built-in.o(.text+0xafef1): In function `pcmcia_bus_hotplug': : undefined reference to `crc32_le' compiling pcmcia modular works. That's a missing dependency on CONFIG_CRC32. Could you check whether this patch helps, please? PCMCIA needs CRC32. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Index: linux-2.6.12-rc1/drivers/pcmcia/Kconfig === --- linux-2.6.12-rc1.orig/drivers/pcmcia/Kconfig2005-03-21 20:07:42.0 +0100 +++ linux-2.6.12-rc1/drivers/pcmcia/Kconfig 2005-03-21 20:12:00.0 +0100 @@ -42,6 +42,7 @@ config PCMCIA tristate 16-bit PCMCIA support + select CRC32 default y ---help--- This option enables support for 16-bit PCMCIA cards. Most older - 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/
PCMCIA bugs in buglist [Was: Re: 2.6.12-rc1-mm1]
From: Sebastian =?iso-8859-1?q?K=FCgler?= [EMAIL PROTECTED] Subject: PCMCIA breaks suspend-to-(disk|ram) with 2.6.11 Fixed by upgrading the userspace script used by him to include cardctl eject sleep 1 before killing cardmgr, as killing cardmgr no longer auto-detaches PCMCIA devices and this was what he needs: while suspend/resume does work with PCMCIA in general AFAIK, certain device drivers are faulty. From: Ron Gage [EMAIL PROTECTED] Subject: Major problem with PCMCIA/Yenta system ... From: Jonas Oreland [EMAIL PROTECTED] Subject: Re: Major problem with PCMCIA/Yenta system This is no regresssion[*], a fix is being evaluated. Thanks, Dominik [*] It may work on 2.4., though... - 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: [PATCH] i386: remove extra spaces from cpu model id
On Sun, Mar 06, 2005 at 08:32:22AM +0100, Daniel Rozsnyo wrote: Removes extra spaces which separate the frequency string from the cpu model id itself (noticable e.g. on Intel Tualatin processors in /proc/cpuinfo) Signed-off-by: Daniel Rozsnyo [EMAIL PROTECTED] This patch breaks speedstep-centrino for 900 MHz Banias CPUs. Also, I'd prefer to keep this the way it is reported by the CPU itself [except the left/right padding], of course. Dominik - 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: Unsupported PM cap regs version 1
On Sat, Mar 05, 2005 at 03:05:35PM -0500, Lee Revell wrote: Every time I load the driver for my SBLive Platinum I get this log message: PCI: :00:0f.0 has unsupported PM cap regs version (1) PM cap regs version 1 is handled in 2.6.11 yet again, the message should be gone for this case by now. even though CONFIG_PM is not set. PM caps are needed to activate devices, even if CONFIG_PM is not set. Dominik - 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/
dereferencing module-internal pointer in scripts/mod/file2alias.c
Hi,
Is there any feasible way to dereference a pointer inside
__mod_*_device_table which points to a string?
e.g.:
include/linux/mod_devicetable.h:
struct pcmcia_device_id {
...
const char * prod_id;
...
}
drivers/some/driver.c:
static struct pcmcia_device_id some_ids[] = {
{.prod_id = some device string, ...},
...
}
MODULE_DEVICE_TABLE(some_ids);
scripts/mod/file2alias.c:
do_pcmcia_entry (..., struct pcmcia_device_id *id, ...)
{
const char *tmp = id-prod_id + SOME_MAGIC_VALUE;
}
Thanks,
Dominik
-
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/
PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Andrew, Linus, all, [note: for detailed code please take a look at 2.6.11-mm2] Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), Only the hashes are stored in modules.alias, and only the hashes calculated upon device insertion are passed to userspace. While having to determine the crc32 hashes is a hassle to device driver authors, I do not see a smart way to generate these (or similar) hashes automatically at compilation time: - the C preprocessor doesn't seem to be smart enough - scripts/mod/file2alias.c would need to learn all architectures (and be cross-compilation aware) to relocate/dereference/access strings saved as const char * prod_id[4]; in struct pcmcia_device_id s To make the life easier for device driver authors, - a big warning is put into dmesg if a pcmcia driver is inserted into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID() is incorrect, - the hash can easily be calculated in userspace from existing /etc/pcmcia/config files, from inserted PCMCIA cards and and and..., - I've added the appropriate hashes for all device matches for drivers in the base linux kernel. Even though I'm a bit uncomfortable with this solution, I do not see any other feasible way. Linus, Andrew, do you agree with this handling despite all the troubles involved with it? Dominik - 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/
inconsistent kallsyms data [2.6.11-mm2]
compiling -mm2 on my x86 box results in: SYSMAP .tmp_System.map Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make: *** [vmlinux] Fehler 1 gcc-Version 3.4.3 20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7) Dominik - 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: inconsistent kallsyms data [2.6.11-mm2]
On Tue, Mar 08, 2005 at 12:35:54PM -0800, Andrew Morton wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: compiling -mm2 on my x86 box results in: SYSMAP .tmp_System.map Inconsistent kallsyms data Try setting CONFIG_KALLSYMS_EXTRA_PASS make: *** [vmlinux] Fehler 1 gcc-Version 3.4.3 20050110 (Gentoo Linux 3.4.3.20050110, ssp-3.4.3.20050110-0, pie-8.7.7) Did CONFIG_KALLSYMS_EXTRA_PASS fix it up? Yes. Dominik - 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: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: #!/bin/sh cd /etc/hotplug . ./hotplug.functions if [ $ACTION = ]; then mesg Bad PCMCIA agent invocation, no action exit 1 fi case $ACTION in add) modprobe $MODNAME ... work around some exotic buggy PCMCIA hardware ... ... and I would very much like to avoid breaking the line modprobe $MODNAME. On Tue, Mar 08, 2005 at 02:54:57PM -0800, Linus Torvalds wrote: On Tue, 8 Mar 2005, Dominik Brodowski wrote: Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), Hmm.. I'm with Andrew on this one - I'd much rather really pass them to user space as strings. We already pass a number of strings as environment variables. In fact, what's wrong with DEVPATH? Which we already expose as the NAME=xxx environment variable. So if the kboject associated with a device has has this string associated with its name (which it should) drivers/base/core.c::device_add() kobject_set_name(dev-kobj, %s, dev-bus_id); and the bus_id isn't the device's name for common buses. Nontheless, the strings _are_ exported at DEVPATH/prod_id[1-4], but for the reasons mentioned above I'd prefer not to use them. On Tue, Mar 08, 2005 at 12:34:26PM -0800, Andrew Morton wrote: ... To make the life easier for device driver authors, - a big warning is put into dmesg if a pcmcia driver is inserted into the kernel and the hash mentioned in PCMCIA_DEVICE_PROD_ID() is incorrect, As long as the kernel shouts loudly at the driver developer at development-time, and that shouting mentions a bit of documentation in Documentation/somewhere, I expect we'll be OK. Andrew, please apply this patch on top of 2.6.11-mm2, if you and Linus still agree: Add some information useful for PCMCIA device driver authors to Documentation/pcmcia/, and reference it in dmesg in case of hash mismatches. Also add a reference to pcmciautils to Documentation/Changes. With recent changes, you don't need to concern yourself with pcmcia-cs even if you have PCMCIA hardware, so the example above the list needed to be adapted as well. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Index: 2.6.11+/Documentation/Changes === --- 2.6.11+.orig/Documentation/Changes 2005-03-08 23:23:30.0 +0100 +++ 2.6.11+/Documentation/Changes 2005-03-08 23:23:33.0 +0100 @@ -44,9 +44,9 @@ Again, keep in mind that this list assumes you are already functionally running a Linux 2.4 kernel. Also, not all tools are -necessary on all systems; obviously, if you don't have any PCMCIA (PC -Card) hardware, for example, you probably needn't concern yourself -with pcmcia-cs. +necessary on all systems; obviously, if you don't have any ISDN +hardware, for example, you probably needn't concern yourself with +isdn4k-utils. o Gnu C 2.95.3 # gcc --version o Gnu make 3.79.1 # make --version @@ -57,6 +57,7 @@ o jfsutils 1.1.3 # fsck.jfs -V o reiserfsprogs 3.6.3 # reiserfsck -V 21|grep reiserfsprogs o xfsprogs 2.6.0 # xfs_db -V +o pcmciautils001 o pcmcia-cs 3.1.21 # cardmgr -V o quota-tools3.09# quota -V o PPP2.4.0 # pppd --version @@ -186,13 +187,20 @@ work correctly with this version of the XFS kernel code (2.6.0 or later is recommended, due to some significant improvements). +PCMCIAutils +--- + +PCMCIAutils replaces pcmcia
Re: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 12:16:36AM +0100, Dominik Brodowski wrote:
Dominik Brodowski [EMAIL PROTECTED] wrote:
Most pcmcia devices are matched to drivers using product ID strings
embedded in the devices' Card Information Structures, as manufactor ID /
card ID matches are much less reliable. Unfortunately, these strings
cannot
be passed to userspace for easy userspace-based loading of appropriate
modules (MODNAME -- hotplug), so my suggestion is to also store crc32
hashes
of the strings in the MODULE_DEVICE_TABLEs, e.g.:
PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11),
What is the difficulty in passing these strings via /sbin/hotplug arguments?
The difficulty is that extracting and evaluating them breaks the wonderful
bus-independent MODNAME implementation for hotplug suggested by Roman Kagan
( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these
strings may contain spaces and other strange characters. The latter may be
worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really
clean because of this MODNAME implementation:
In addition: this isn't the problematic part. The product ID string and/or
the hash can easily be passed from kernelspace to userspace in calls to
hotplug, and that's not the real reason for the hashing. Instead, it is
caused by the module.alias generation (even module.pcmciamap, if it existed,
wouldn't be of help here) at compilation time: the format of such aliases is
alias [bus_name]:[{one or multiple chars as separators}{NUMBERS!} multiple such
blocks] [module_name]
This means: only (hex) numbers are allowed as _values_ in such a module alias
map. The module alias map is generated by file2alias.c, which cannot and
should not be able to access strings inside modules, because that would mean
awareness of all sorts of (arch-dependant) relocation. Therefore,
file2alias.c can't calculate the hashes for us, and as the C preprocessor
cannot either, only the explicit passing of strings _and_ hashes to struct
pcmcia_device_id-generating macros is the only feasible way I currently see
to use module.alias for PCMCIA devices.
Dominik
-
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: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Tue, Mar 08, 2005 at 03:37:07PM -0800, Greg KH wrote: module aliases, and fixing up modprobe to handle spaces in module aliases wouldn't work out easier. spaces _and_ characters. And characters are already used to separate different fields. pcmcia:pasome stringpbsome other string doesn't look bad though, indeed. Problem is: how to access the strings in file2alias.c? They're in different sections than the __mod_devicetables, and you'd need to get architecture-dependant relocation... so this doesn't seem feasible... or am I missing something? Dominik - 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: PCMCIA product id strings - hashes generation at compilation time? [Was: Re: [patch 14/38] pcmcia: id_table for wavelan_cs]
On Wed, Mar 09, 2005 at 04:45:09PM +1100, Benjamin Herrenschmidt wrote: On Wed, 2005-03-09 at 00:16 +0100, Dominik Brodowski wrote: Dominik Brodowski [EMAIL PROTECTED] wrote: Most pcmcia devices are matched to drivers using product ID strings embedded in the devices' Card Information Structures, as manufactor ID / card ID matches are much less reliable. Unfortunately, these strings cannot be passed to userspace for easy userspace-based loading of appropriate modules (MODNAME -- hotplug), so my suggestion is to also store crc32 hashes of the strings in the MODULE_DEVICE_TABLEs, e.g.: PCMCIA_DEVICE_PROD_ID12(LINKSYS, E-CARD, 0xf7cb0b07, 0x6701da11), What is the difficulty in passing these strings via /sbin/hotplug arguments? The difficulty is that extracting and evaluating them breaks the wonderful bus-independent MODNAME implementation for hotplug suggested by Roman Kagan ( http://article.gmane.org/gmane.linux.hotplug.devel/7039 ), and that these strings may contain spaces and other strange characters. The latter may be worked around, but the former cannot. /etc/hotplug/pcmcia.agent looks really clean because of this MODNAME implementation: Same goes with Open Firmware match strings that we are about to pass down to userspace as well. Hotplug will have to learn to deal with those. Hotplug isn't the tricky part. file2alias is. Any idea on how to do that? Dominik - 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: [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule
On Wed, Mar 09, 2005 at 04:34:38PM -0800, Greg KH wrote: ChangeSet 1.2036, 2005/03/09 09:31:40-08:00, [EMAIL PROTECTED] [PATCH] Add 2.4.x cpufreq /proc and sysctl interface removal feature-removal-schedule Add 2.4.x cpufreq /proc and sysctl interface removal to the feature-removal-schedule. [PATCH] cpufreq 2.4 interface removal schedule Even though these 2.4. interfaces are already gone in Dave Jones' cpufreq bitkeeper tree, here's a patch which properly announces it in Documentation/feature-removal-schedule.txt: Both already _were_ in Linus' tree; the entry got removed along with the cpufreq 2.4. interface. So please do not re-add this entry. Dominik - 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: PCMCIA Oops (was Re: 2.6.12-rc1-mm3)
On Sat, Mar 26, 2005 at 07:39:29PM +, Sean Neakums wrote:
On a PowerBook5.4 I get the below when I insert the PCMCIA card or
boot with it inserted; however, if I boot with no card inserted,
sleep-resume and insert the card it works fine. Similar with
2.6.12-rc1-mm1; not sure why I didn't notice until now, since I
happily used it for six days or so, PCMCIA and all, although there was
*some* PCMCIA-related issue I failed to note and cannot now recall.
If you revert the patch named
pcmcia-mark-parent-bridge-windows-as-resources-available-for-pcmcia-devices.patch
the oops should disappear. However, I had no chance yet to fully debug
what's going on here. So I'd prefer it if you first applied the attached test
patch and sent me (off-list) the dmesg output. Also, it is very strange that
it doesn't trigger if you did a sleep-resume cycle before... Ben, any idea?
Dominik
Index: 2.6.12-rc1/drivers/pcmcia/cistpl.c
===
--- 2.6.12-rc1.orig/drivers/pcmcia/cistpl.c 2005-03-25 13:49:21.0
+0100
+++ 2.6.12-rc1/drivers/pcmcia/cistpl.c 2005-03-25 13:50:26.0 +0100
@@ -89,6 +89,7 @@
set_cis_map(struct pcmcia_socket *s, unsigned int card_offset, unsigned int
flags)
{
pccard_mem_map *mem = s-cis_mem;
+int ret;
if (!(s-features SS_CAP_STATIC_MAP) mem-res == NULL) {
mem-res = pcmcia_find_mem_region(0, s-map_size, s-map_size, 0, s);
if (mem-res == NULL) {
@@ -99,7 +100,9 @@
}
mem-card_start = card_offset;
mem-flags = flags;
-s-ops-set_mem_map(s, mem);
+printk(KERN_DEBUG set_cis_map: %x %u %lx %lx %p\n, card_offset, flags,
mem-res-start, mem-res-end, s-cis_virt);
+ret = s-ops-set_mem_map(s, mem);
+printk(KERN_DEBUG ret is %i\n, ret);
if (s-features SS_CAP_STATIC_MAP) {
if (s-cis_virt)
iounmap(s-cis_virt);
Index: 2.6.12-rc1/drivers/pcmcia/rsrc_nonstatic.c
===
--- 2.6.12-rc1.orig/drivers/pcmcia/rsrc_nonstatic.c 2005-03-25
13:49:21.0 +0100
+++ 2.6.12-rc1/drivers/pcmcia/rsrc_nonstatic.c 2005-03-25 13:54:10.0
+0100
@@ -93,6 +93,8 @@
{
struct resource *res, *parent;
+ printk(KERN_DEBUG claim_region: %lx, %lx\n, base, size);
+
parent = type IORESOURCE_MEM ? iomem_resource : ioport_resource;
res = make_resource(base, size, type | IORESOURCE_BUSY, name);
@@ -106,6 +108,9 @@
res = NULL;
}
}
+
+ printk(KERN_DEBUG claim_region: result %p\n, res);
+
return res;
}
@@ -267,8 +272,12 @@
{
int ret = -1;
+ printk(KERN_DEBUG readable: %lx %x\n, res-start, s-map_size);
+
s-cis_mem.res = res;
s-cis_virt = ioremap(res-start, s-map_size);
+
+ printk(KERN_DEBUG readable: remapped to %p\n, s-cis_virt);
if (s-cis_virt) {
ret = pccard_validate_cis(s, BIND_FN_ALL, info);
/* invalidate mapping and CIS cache */
@@ -290,6 +299,7 @@
void __iomem *virt;
virt = ioremap(res-start, s-map_size);
+ printk(checksum: %lx, %x remapped to %p\n, res-start, s-map_size,
virt);
if (virt) {
map.map = 0;
map.flags = MAP_ACTIVE;
@@ -324,6 +334,8 @@
res1 = claim_region(s, base, size/2, IORESOURCE_MEM, cs memory probe);
res2 = claim_region(s, base + size/2, size/2, IORESOURCE_MEM, cs
memory probe);
+ printk(KERN_DEBUG cis_readable: %lx (%lx) - %p, %lx (%lx) - %p\n,
base, (size/2), res1, (base + size/2), (size/2), res2);
+
if (res1 res2) {
ret = readable(s, res1, info1);
ret += readable(s, res2, info2);
@@ -375,6 +387,7 @@
/* cis_readable wants to map 2x map_size */
if (step 2 * s-map_size)
step = 2 * s-map_size;
+printk(KERN_DEBUG do_mem_probe %lx %lx %lx\n, base, num, step);
for (i = j = base; i base+num; i = j + step) {
if (!fail) {
for (j = i; j base+num; j += step) {
Re: [RFC] Changes to the driver model class code.
On Tue, Mar 15, 2005 at 02:14:31PM -0800, Greg KH wrote:
It will not make the reference counting logic easier to get wrong, or
easier to get right. It totally takes it away from the user, and makes
them implement it themselves if they so wish (like the USB HCD patch
does.)
Hi,
While looking more closely at your patches, I noticed the following race:
A) attribute is opened - class_device's reference count is increased
B) usb/host/ohci-dbg.c::remove_debug_files() -- succeeds, as it doesn't check
class_device's reference count()
B) usb/core/hcd.c::usb_deregister_count() -- class_device_unregister doesn't
wait until class_device's reference count reaches zero, so
struct class_device still has struct usb_bus *bus saved as class_data
and continues to exist.
B) possibly the kref count of struct usb_bus reaches zero, and struct usb_bus *
is kfreed.
A) attribute is read - e.g. usb/host/ohci-dbg.c::show_periodic()
bus = class_get_devdata(class_dev);
hcd = bus-hcpriv;
-- accessing kfree'd structure. Ooops.
A) ... [if it hadn't oopsed] attribute is closed, reference count reaches zero,
class_device is removed.
If both reference counts were kept unified (as with previous struct
class{,_device} design) this couldn't happen. The proper reference counting
for dynamically allocated objects and their attributes is _the_ advantage
of sysfs/driver model in favour of procfs.
Or am I missing something?
Thanks and Happy Easter,
Dominik
-
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: [RFC] Some thoughts on device drivers and sysfs
On Sun, Mar 27, 2005 at 02:24:59PM -0500, Adam Belay wrote: One of the original design goals of sysfs was to provide a standardized location to keep driver configuration attributes. Although sysfs handles this very well for bus devices and class devices, there isn't currently a method to export attributes for device drivers and their specific bound device instances to userspace. Drivers can add (e.g. in -probe) attributes for devices using extern int device_create_file(struct device *device, struct device_attribute * entry); and delete them (e.g. in -remove) using extern void device_remove_file(struct device * dev, struct device_attribute * attr); and there's also extern int driver_create_file(struct device_driver *, struct driver_attribute *); extern void driver_remove_file(struct device_driver *, struct driver_attribute *); Dominik - 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: [RFC] Some thoughts on device drivers and sysfs
On Sun, Mar 27, 2005 at 04:27:24PM -0500, Adam Belay wrote: extern int device_create_file(struct device *device, struct device_attribute * entry); and delete them (e.g. in -remove) using extern void device_remove_file(struct device * dev, struct device_attribute * attr); and there's also extern int driver_create_file(struct device_driver *, struct driver_attribute *); extern void driver_remove_file(struct device_driver *, struct driver_attribute *); Dominik Yes, I'm aware of these functions but they pollute the bus level namespace. I'm interested in reactions to this alternative approach. I wanted to explore the possibility of making a device driver instance a separate component with its own individual state and relationships. To be honest, I don't consider this to be a pollution of the bus namespace, but I fear that having two different places for somewhat similar, or even equal, data adds unneeded complexity to the driver model. In what specific instances has the current design limited or obstructed your intentions? Dominik - 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: Clock 3x too fast on AMD64 laptop [WAS Re: Various issues after rebooting]
On Wed, Mar 30, 2005 at 12:02:11AM +0200, Olivier Fourdan wrote: Hi, A quick look at the source shows that the error is triggered in arch/i386/kernel/timers/timer_pm.c by the verify_pmtr_rate() function. My guess is that the pmtmr timer is right and the pit is wrong in my case. That would explain why the clock is wrong when being based on pit (like when forced with clock=pit) Maybe, if I can prove my guesses, a fix could be to trust the pmtmr clock when the user has passed a clock=pmtmr argument ? Does that make any sense ? This would make a lot of sense, IMHO. John, what do you think? Dominik - 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: IBM Thinkpad G41 PCMCIA problems
On Sun, Feb 20, 2005 at 10:52:12AM +0100, David Härdeman wrote: On Sun, Feb 20, 2005 at 09:26:59AM +, Russell King wrote: On Sun, Feb 20, 2005 at 10:22:09AM +0100, David Härdeman wrote: I see the same problem with an IBM Thinkpad G40, and only when there is 1Gb of memory or more in the machine. Check to see if your e820 map has a hole in it, and whether any of your Cardbus bridge memory / region 0 resources appear in it. If your e820 map contains a hole, I'd suspect another buggy bios. e820 map: BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000dc000 - 0010 (reserved) BIOS-e820: 0010 - 0f6f (usable) BIOS-e820: 0f6f - 0f70 (reserved) BIOS-e820: 0f70 - 3f6f (usable) BIOS-e820: 3f6f - 3f6f8000 (ACPI data) BIOS-e820: 3f6f8000 - 3f6fa000 (ACPI NVS) BIOS-e820: 3f70 - 4000 (reserved) BIOS-e820: ff80 - 0001 (reserved) 118MB HIGHMEM available. 896MB LOWMEM available. Is the hole between 0x36f6fa000 and 0x3f70? And what would be the proper way of fixing it (assuming that IBM won't issue a fixed BIOS)? passing reserve=0x3f6fa000,0x600 as kernel boot option. Please also post /proc/iomem for further debugging, especially if this didn't help. Dominik - 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.11-rc4-mm1
Hi, On Wed, Feb 23, 2005 at 07:20:09PM +0100, Brice Goglin wrote: Andrew Morton a écrit : ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc4/2.6.11-rc4-mm1/ I can't get PCMCIA to work anymore since rc4-mm1. It was working great with rc4 and rc3-mm1. PCMCIA loads without any apparent problem (see attached dmesg). One thing surprises me: the sockets don't get IO resources allocated: yenta :02:03.1: no resource of type 100 available, trying to continue... yenta :02:03.1: no resource of type 100 available, trying to continue... which doesn't happen in earlier kernels. In lspci this shows itself as: I/O window 0: -0003 I/O window 1: -0003 Which one(s) do you think might be responsible for this ? My gut tells me +pcmcia-bridge-resource-management-fix.patch is responsible for this no resource available message, because the other ones relate to other areas. If the error persists, it'd be great if you could apply the other PCMCIA patches to the working -rc4 tree and check if it continues to work -- or, the other way round, removing the PCMCIA patches completely and checking whether it works then. Thanks, Dominik - 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: [8/14] Orinoco driver updates - PCMCIA initialization cleanups
@@ -184,6 +186,7 @@ dev_list = link; client_reg.dev_info = dev_info; + client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; That's not needed any longer for 2.6. Dominik - 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: [Orinoco-devel] Re: [8/14] Orinoco driver updates - PCMCIA initialization cleanups
On Fri, Feb 25, 2005 at 04:03:10PM +1100, David Gibson wrote: On Thu, Feb 24, 2005 at 02:29:05AM -0500, Jeff Garzik wrote: Dominik Brodowski wrote: @@ -184,6 +186,7 @@ dev_list = link; client_reg.dev_info = dev_info; + client_reg.Attributes = INFO_IO_CLIENT | INFO_CARD_SHARE; That's not needed any longer for 2.6. So who wants to send the incremental update patch? :) Guess I will. See below. Any particular reason the field and associated constants haven't been exunged from the tree, since they're no longer used? To keep external drivers compiling -- it'll be removed soon, though. Dominik - 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: unsupported PCI PM caps (again?)
On Mon, Feb 28, 2005 at 01:31:03AM +0100, Christian Kujau wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 hi, i'm running 2.6.11-rc2-bk10 and still get my syslog clobbered with messages like this: PCI: :00:0c.0 has unsupported PM cap regs version (1) $ lspci | grep :00:0c.0 :00:0c.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 30) so everytime i use my eth0, a few more messages appear. 2.6.11-rc2-bk10 was released on Feb 2 i think, but bk changes reveals: [EMAIL PROTECTED], 2005-01-14 15:58:36-08:00, [EMAIL PROTECTED] [PATCH] PCI: Downgrade printk that complains about unsupported PCI PM caps my network card is working fine, what can i do to disable these messages? i am NOT using APM or ACPI. As the unsupported PCI PM cap regs version (1) handling caused trouble on some devices, it got removed in 2.6.11-rc5. Dominik - 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.11-rc4-mm1 - pcmcia weirdness/breakage
On Mon, Feb 28, 2005 at 02:48:20PM -0500, [EMAIL PROTECTED] wrote: Symptoms: Running '/etc/init.d/pcmcia start' bombs - cardmgr goes into a loop spewing repeated 'Common memory region at 0x0: Generic or SRAM' messages. In the dmesg, we find: [4294764.989000] 6cs: IO port probe 0xc00-0xcff: clean. [4294859.195000] cs: IO port probe 0xc00-0xcff: clean. [4294859.195000] cs: IO port probe 0xc00-0xcff: clean. [4294859.199000] cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 0x370-0x37f [4294859.202000] cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 0x370-0x37f [4294859.205000] cs: IO port probe 0x100-0x4ff: excluding 0x170-0x177 0x370-0x37f [4294859.207000] cs: IO port probe 0xa00-0xaff: clean. [4294859.208000] cs: IO port probe 0xa00-0xaff: clean. [4294859.209000] cs: IO port probe 0xa00-0xaff: clean. [4294859.369000] cs: unable to map card memory! [4294859.369000] cs: unable to map card memory! Now the odd part: 2.6.11-rc4 works, doesn't show the last 2 'unable to map' messages. 2.6.11-rc4 + linus.patch from -rc4-mm1 works as well - so it's a -mm patch doing it. A full -rc4-mm1 fails, *as does* a -rc4-mm1 with all the following patches -R'ed: broken-out/fix-u32-vs-pm_message_t-confusion-in-pcmcia.patch broken-out/pcmcia-add-pcmcia-devices-autonomously.patch broken-out/pcmcia-bridge-resource-management-fix.patch broken-out/pcmcia-determine-some-useful-information-about-devices.patch broken-out/pcmcia-mark-resource-setup-as-done.patch broken-out/pcmcia-pcmcia_device_add.patch broken-out/pcmcia-pcmcia_device_probe.patch broken-out/pcmcia-pcmcia_device_remove.patch broken-out/pcmcia-pd6729-convert-to-pci_register_driver.patch broken-out/pcmcia-per-device-sysfs-output.patch broken-out/pcmcia-rsrc_nonstatic-sysfs-input.patch broken-out/pcmcia-rsrc_nonstatic-sysfs-output.patch broken-out/pcmcia-update-vrc4171_card.patch broken-out/pcmcia-use-bus_rescan_devices.patch broken-out/pcmcia-yenta_socket-ti4150-support.patch So the breakage is in *some other* -rc4-mm1 patch. Any hints to speed up the binary search? Most likely it's pcmcia-bridge-resource-management-fix.patch Dominik - 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: Fw: Re: 2.6.11-rc5-mm1
On Tue, Mar 01, 2005 at 11:57:03AM +0100, Alexander Gran wrote: Am Dienstag, 1. März 2005 11:48 schrieb Andrew Morton: Alex, please use mailing lists... sorry, I was used to have reply-to set to the mailing list ;) double-checking next time.. Dominik, do we really always want to drag in the firmware loader if CONFIG_PCMCIA? Hmm. I've enabled the firmware loader that fixes at least the compile error... Now rebooting. More info after my system programming exam in 1 hour. ;) Updated patch submitted -- see http://lists.infradead.org/pipermail/linux-pcmcia/2005-March/001580.html Dominik - 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: kernel BUG at drivers/serial/8250.c:1256!
On Tue, Mar 01, 2005 at 11:37:20PM +, Russell King wrote:
On Wed, Mar 02, 2005 at 12:09:46AM +0100, Karol Kozimor wrote:
I've finally got around to test latest kernels and managed to find a bug in
the serial subsystem, which happens during suspend.
Yes, serial_cs is claiming that we don't have a device associated with
the port, so we're treating it as a legacy port. However, serial_cs is
implementing the suspend/resume methods. This is wrong, since that
means the port will be suspended twice, and hence causes this bug.
serial_cs needs to register the ports along with the PCMCIA device with
which the port belongs to. This will stop it being treated as a legacy
serial port.
Unfortunately, it's too late tonight for me to dig into PCMCIA to work
out how we get at the device structure - I can't find any examples off
hand either.
For the time being:
{
client_handle_t handle = ...
struct device *dev;
dev = handle_to_dev(handle);
}
Dominik
-
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.10] PCMCIA/CardBus Wifi Card Problem
Hi, On Thu, Jan 27, 2005 at 01:36:37AM +0100, Emmanuel Fleury wrote: Module Size Used by orinoco_cs 9000 1 orinoco41324 1 orinoco_cs hermes 8896 2 orinoco_cs,orinoco CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set # CONFIG_PCMCIA_OBSOLETE is not set # CONFIG_PCMCIA is not set CONFIG_PCMCIA needs to be set to y or m, and then you need to enable the appropriate config options for orinoco PCMCIA cards. Oh, and it doesn't seem to be a CardBus card (32-bit) but to be a 16-bit PCMCIA card. Dominik - 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: cpufreq problem wrt suspend/resume on Athlon64
Hi, On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote: Okay, you are right, restoring it unconditionaly would be bad idea. Still it would be nice to tell cpufreq governor please change the frequency ASAP so it does not run at 800MHz for half an hour compiling kernels on AC power. It already does that... or at least it should. in cpufreq_resume() there is a call to schedule_work(cpu_policy-update); which will cause a call cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the governor, and it is supposed to adjust the frequency to the user's wish then. Dominik - 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: cpufreq problem wrt suspend/resume on Athlon64
On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote: Hi! On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote: Okay, you are right, restoring it unconditionaly would be bad idea. Still it would be nice to tell cpufreq governor please change the frequency ASAP so it does not run at 800MHz for half an hour compiling kernels on AC power. It already does that... or at least it should. in cpufreq_resume() there is a call to schedule_work(cpu_policy-update); which will cause a call cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the governor, and it is supposed to adjust the frequency to the user's wish then. Ok, so Rafael's suspend() routine seems like good fix... No. I don't see a reason why my desktop P4 should drop to 12.5 frequency (p4-clockmod) if I ask it to suspend to mem. Dominik - 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: cpufreq problem wrt suspend/resume on Athlon64
On Thu, Feb 03, 2005 at 12:30:19PM +0100, Rafael J. Wysocki wrote: On Thursday, 3 of February 2005 12:01, Dominik Brodowski wrote: On Thu, Feb 03, 2005 at 11:58:46AM +0100, Pavel Machek wrote: Hi! On Thu, Feb 03, 2005 at 11:41:26AM +0100, Pavel Machek wrote: Okay, you are right, restoring it unconditionaly would be bad idea. Still it would be nice to tell cpufreq governor please change the frequency ASAP so it does not run at 800MHz for half an hour compiling kernels on AC power. It already does that... or at least it should. in cpufreq_resume() there is a call to schedule_work(cpu_policy-update); which will cause a call cpufreq_update_policy() in due course. And cpufreq_update_policy() calls the governor, and it is supposed to adjust the frequency to the user's wish then. Ok, so Rafael's suspend() routine seems like good fix... No. I don't see a reason why my desktop P4 should drop to 12.5 frequency (p4-clockmod) if I ask it to suspend to mem. So, would it be acceptable to check in _suspend() if the state is S4 and drop the frequency in that case or do nothing otherwise? No. The point is that this is _very_ system-specific. Some systems resume always at full speed, some always at low speed; for S4 the behaviour may be completely unpredictable. And in fact I wouldn't want my desktop P4 drop th 12.5 % frequency if I ask it to suspend to disk, too. Ignoring the warning seems to be the best thing to me. The good thing is, after all, that cpufreq detected this situation and tries to correct for it. Dominik - 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/
[RFC][PATCH 1/4] rwsem style cleanups
From: Nick Piggin [EMAIL PROTECTED]
Changes some coding style and formatting to match David's preference.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
linux-2.6-npiggin/lib/rwsem-spinlock.c | 12 +++-
linux-2.6-npiggin/lib/rwsem.c | 20 +---
2 files changed, 20 insertions(+), 12 deletions(-)
diff -puN lib/rwsem.c~rwsem-style lib/rwsem.c
--- linux-2.6/lib/rwsem.c~rwsem-style 2005-01-19 13:34:48.0 +1100
+++ linux-2.6-npiggin/lib/rwsem.c 2005-01-19 13:39:06.0 +1100
@@ -9,9 +9,9 @@
#include linux/module.h
struct rwsem_waiter {
- struct list_head list;
- struct task_struct *task;
- unsigned int flags;
+ struct list_headlist;
+ struct task_struct *task;
+ unsigned intflags;
#define RWSEM_WAITING_FOR_READ 0x0001
#define RWSEM_WAITING_FOR_WRITE0x0002
};
@@ -28,7 +28,8 @@ void rwsemtrace(struct rw_semaphore *sem
#endif
/*
- * handle the lock release when processes blocked on it that can now run
+ * handle the lock being released whilst there are processes blocked on it
+ * that can now run.
* - if we come here from up_(), then:
* - the 'active part' of count (0x) reached 0 (but may have
changed)
* - the 'waiting part' of count (0x) is -ve (and will still be so)
@@ -62,8 +63,9 @@ __rwsem_do_wake(struct rw_semaphore *sem
waiter = list_entry(sem-wait_list.next, struct rwsem_waiter, list);
/* try to grant a single write lock if there's a writer at the front
-* of the queue - note we leave the 'active part' of the count
-* incremented by 1 and the waiting part incremented by 0x0001
+* of the queue
+* - note we leave the 'active part' of the count
+* incremented by 1 and the waiting part incremented by 0x0001
*/
if (!(waiter-flags RWSEM_WAITING_FOR_WRITE))
goto readers_only;
@@ -159,7 +161,11 @@ rwsem_down_failed_common(struct rw_semap
/* we're now waiting on the lock, but no longer actively read-locking */
count = rwsem_atomic_update(adjustment, sem);
- /* if there are no active locks, wake the front queued process(es) up */
+ /* if there are no longer active locks, wake the front queued
+* process(es) up.
+* - it might even be this process, since the waker takes a more
+* active part
+*/
if (!(count RWSEM_ACTIVE_MASK))
sem = __rwsem_do_wake(sem, 0);
diff -puN lib/rwsem-spinlock.c~rwsem-style lib/rwsem-spinlock.c
--- linux-2.6/lib/rwsem-spinlock.c~rwsem-style 2005-01-19 13:34:48.0
+1100
+++ linux-2.6-npiggin/lib/rwsem-spinlock.c 2005-01-19 13:39:06.0
+1100
@@ -10,9 +10,9 @@
#include linux/module.h
struct rwsem_waiter {
- struct list_head list;
- struct task_struct *task;
- unsigned int flags;
+ struct list_headlist;
+ struct task_struct *task;
+ unsigned intflags;
#define RWSEM_WAITING_FOR_READ 0x0001
#define RWSEM_WAITING_FOR_WRITE0x0002
};
@@ -41,7 +41,8 @@ void fastcall init_rwsem(struct rw_semap
}
/*
- * handle the lock release when processes blocked on it that can now run
+ * handle the lock being released whilst there are processes blocked on it
+ * that can now run.
* - if we come here, then:
* - the 'active count' _reached_ zero
* - the 'waiting count' is non-zero
@@ -83,7 +84,8 @@ __rwsem_do_wake(struct rw_semaphore *sem
goto out;
}
- /* grant an infinite number of read locks to the front of the queue */
+ /* grant an infinite number of read locks to the readers at the front
+* of the queue */
dont_wake_writers:
woken = 0;
while (waiter-flags RWSEM_WAITING_FOR_READ) {
_
-
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/
[RFC][PATCH 0/4] interruptible rwsem and their usage for cpucontrol
The following four patches add support for interruptible trying to grab R/W-semaphores (patches by Nick Piggin), and use (interruptible) rwsems to improve the disabling of CPU hotplug operations. The latter was already discussed earlier on this list[1]. Dominik [1] http://marc.theaimsgroup.com/?t=10992989821r=1w=2 - 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/
[RFC][PATCH 2/4] interruptible rwsem operations (i386, core)
From: Nick Piggin [EMAIL PROTECTED]
Add functions down_read_interruptible, and down_write_interruptible to rw
semaphores. Implement these for i386.
Other architectures should be fairly straight forward - the functions are
basically identical to down_read / down_write, but must just catch and
return the value from the out-of-line function in the case that the semaphore
is contended.
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
linux-2.6-npiggin/include/asm-i386/rwsem.h | 75 -
linux-2.6-npiggin/include/linux/rwsem-spinlock.h |2
linux-2.6-npiggin/include/linux/rwsem.h | 28
linux-2.6-npiggin/lib/rwsem-spinlock.c | 132 +++
linux-2.6-npiggin/lib/rwsem.c| 114 ++-
5 files changed, 337 insertions(+), 14 deletions(-)
diff -puN lib/rwsem.c~rwsem-interruptible lib/rwsem.c
--- linux-2.6/lib/rwsem.c~rwsem-interruptible 2005-01-19 13:39:39.0
+1100
+++ linux-2.6-npiggin/lib/rwsem.c 2005-01-19 13:39:39.0 +1100
@@ -142,8 +142,7 @@ __rwsem_do_wake(struct rw_semaphore *sem
/*
* wait for a lock to be granted
*/
-static inline struct rw_semaphore *
-rwsem_down_failed_common(struct rw_semaphore *sem,
+static inline void rwsem_down_failed_common(struct rw_semaphore *sem,
struct rwsem_waiter *waiter, signed long adjustment)
{
struct task_struct *tsk = current;
@@ -180,15 +179,70 @@ rwsem_down_failed_common(struct rw_semap
}
tsk-state = TASK_RUNNING;
+}
- return sem;
+/*
+ * interruptible wait for a lock to be granted
+ */
+static inline int
+rwsem_down_interruptible_failed_common(struct rw_semaphore *sem,
+ struct rwsem_waiter *waiter, signed long adjustment)
+{
+ struct task_struct *tsk = current;
+ signed long count;
+ int ret = 0;
+
+ if (signal_pending(current))
+ return -EINTR;
+
+ set_task_state(tsk, TASK_INTERRUPTIBLE);
+
+ /* set up my own style of waitqueue */
+ spin_lock(sem-wait_lock);
+ waiter-task = tsk;
+ get_task_struct(tsk);
+
+ list_add_tail(waiter-list, sem-wait_list);
+
+ /* we're now waiting on the lock, but no longer actively read-locking */
+ count = rwsem_atomic_update(adjustment, sem);
+
+ /* if there are no active locks, wake the front queued process(es) up */
+ if (!(count RWSEM_ACTIVE_MASK))
+ sem = __rwsem_do_wake(sem, 0);
+
+ spin_unlock(sem-wait_lock);
+
+ /* wait to be given the lock */
+ for (;;) {
+ if (!waiter-task)
+ break;
+ if (signal_pending(current)) {
+ spin_lock(sem-wait_lock);
+ if (!waiter-task) {
+ spin_unlock(sem-wait_lock);
+ break;
+ }
+ list_del(waiter-list);
+ rwsem_atomic_add(-adjustment, sem);
+ spin_unlock(sem-wait_lock);
+ ret = -EINTR;
+ break;
+ }
+
+ schedule();
+ set_task_state(tsk, TASK_INTERRUPTIBLE);
+ }
+
+ tsk-state = TASK_RUNNING;
+
+ return ret;
}
/*
* wait for the read lock to be granted
*/
-struct rw_semaphore fastcall __sched *
-rwsem_down_read_failed(struct rw_semaphore *sem)
+void fastcall __sched rwsem_down_read_failed(struct rw_semaphore *sem)
{
struct rwsem_waiter waiter;
@@ -199,14 +253,33 @@ rwsem_down_read_failed(struct rw_semapho
RWSEM_WAITING_BIAS - RWSEM_ACTIVE_BIAS);
rwsemtrace(sem, Leaving rwsem_down_read_failed);
- return sem;
+}
+
+/*
+ * interruptible wait for the read lock to be granted
+ */
+int fastcall __sched
+rwsem_down_read_interruptible_failed(struct rw_semaphore *sem)
+{
+ struct rwsem_waiter waiter;
+ int ret;
+
+ rwsemtrace(sem, Entering rwsem_down_read_interruptible_failed);
+
+ waiter.flags = RWSEM_WAITING_FOR_READ;
+ ret = rwsem_down_interruptible_failed_common(sem, waiter,
+ RWSEM_WAITING_BIAS - RWSEM_ACTIVE_BIAS);
+ if (ret == -EINTR)
+ up_read(sem);
+
+ rwsemtrace(sem, Leaving rwsem_down_read_interruptible_failed);
+ return ret;
}
/*
* wait for the write lock to be granted
*/
-struct rw_semaphore fastcall __sched *
-rwsem_down_write_failed(struct rw_semaphore *sem)
+void fastcall __sched rwsem_down_write_failed(struct rw_semaphore *sem)
{
struct rwsem_waiter waiter;
@@ -216,10 +289,31 @@ rwsem_down_write_failed(struct rw_semaph
rwsem_down_failed_common(sem, waiter, -RWSEM_ACTIVE_BIAS);
rwsemtrace(sem, Leaving rwsem_down_write_failed);
- return sem;
}
/*
+ * interruptible wait
[RFC][PATCH 4/4] use disable_cpu_hotplug() instead of lock_cpu_hotplug() where appropriate
Use {dis,en}able_cpu_hotplug() instead of {un,}lock_cpu_hotplug() in
obvious(?) places which don't need serialization (or provide it on their
own) and don't need to be serialized against each other (like ppc64's rtasd
and cpufreq).
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
arch/ppc64/kernel/rtasd.c | 10 +-
drivers/cpufreq/cpufreq.c |4 ++--
kernel/sched.c| 14 +++---
kernel/stop_machine.c |4 ++--
net/core/flow.c |4 ++--
5 files changed, 18 insertions(+), 18 deletions(-)
Index: 2.6.11-rc1+/arch/ppc64/kernel/rtasd.c
===
--- 2.6.11-rc1+.orig/arch/ppc64/kernel/rtasd.c 2005-01-16 23:15:25.0
+0100
+++ 2.6.11-rc1+/arch/ppc64/kernel/rtasd.c 2005-01-18 19:54:21.0
+0100
@@ -437,7 +437,7 @@
}
/* First pass. */
- lock_cpu_hotplug();
+ disable_cpu_hotplug();
for_each_online_cpu(cpu) {
DEBUG(scheduling on %d\n, cpu);
set_cpus_allowed(current, cpumask_of_cpu(cpu));
@@ -447,7 +447,7 @@
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout(HZ);
}
- unlock_cpu_hotplug();
+ enable_cpu_hotplug();
if (surveillance_timeout != -1) {
DEBUG(enabling surveillance\n);
@@ -455,7 +455,7 @@
DEBUG(surveillance enabled\n);
}
- lock_cpu_hotplug();
+ disable_cpu_hotplug();
cpu = first_cpu(cpu_online_map);
for (;;) {
set_cpus_allowed(current, cpumask_of_cpu(cpu));
@@ -465,10 +465,10 @@
/* Drop hotplug lock, and sleep for a bit (at least
* one second since some machines have problems if we
* call event-scan too quickly). */
- unlock_cpu_hotplug();
+ enable_cpu_hotplug();
set_current_state(TASK_INTERRUPTIBLE);
schedule_timeout((HZ*60/rtas_event_scan_rate) / 2);
- lock_cpu_hotplug();
+ disable_cpu_hotplug();
cpu = next_cpu(cpu, cpu_online_map);
if (cpu == NR_CPUS)
Index: 2.6.11-rc1+/drivers/cpufreq/cpufreq.c
===
--- 2.6.11-rc1+.orig/drivers/cpufreq/cpufreq.c 2005-01-16 23:23:11.0
+0100
+++ 2.6.11-rc1+/drivers/cpufreq/cpufreq.c 2005-01-18 19:53:13.0
+0100
@@ -1027,12 +1027,12 @@
unsigned int relation)
{
int retval = -EINVAL;
- lock_cpu_hotplug();
+ disable_cpu_hotplug();
dprintk(target for CPU %u: %u kHz, relation %u\n, policy-cpu,
target_freq, relation);
if (cpu_online(policy-cpu) cpufreq_driver-target)
retval = cpufreq_driver-target(policy, target_freq, relation);
- unlock_cpu_hotplug();
+ enable_cpu_hotplug();
return retval;
}
EXPORT_SYMBOL_GPL(__cpufreq_driver_target);
Index: 2.6.11-rc1+/kernel/sched.c
===
--- 2.6.11-rc1+.orig/kernel/sched.c 2005-01-16 23:23:12.0 +0100
+++ 2.6.11-rc1+/kernel/sched.c 2005-01-18 19:56:59.0 +0100
@@ -3422,13 +3422,13 @@
task_t *p;
int retval;
- lock_cpu_hotplug();
+ disable_cpu_hotplug();
read_lock(tasklist_lock);
p = find_process_by_pid(pid);
if (!p) {
read_unlock(tasklist_lock);
- unlock_cpu_hotplug();
+ enable_cpu_hotplug();
return -ESRCH;
}
@@ -3449,7 +3449,7 @@
out_unlock:
put_task_struct(p);
- unlock_cpu_hotplug();
+ enable_cpu_hotplug();
return retval;
}
@@ -3503,7 +3503,7 @@
int retval;
task_t *p;
- lock_cpu_hotplug();
+ disable_cpu_hotplug();
read_lock(tasklist_lock);
retval = -ESRCH;
@@ -3516,7 +3516,7 @@
out_unlock:
read_unlock(tasklist_lock);
- unlock_cpu_hotplug();
+ enable_cpu_hotplug();
if (retval)
return retval;
@@ -4309,8 +4309,8 @@
BUG_ON(rq-nr_running != 0);
/* No need to migrate the tasks: it was best-effort if
-* they didn't do lock_cpu_hotplug(). Just wake up
-* the requestors. */
+* they didn't do lock_cpu_hotplug() or disable_cpu_hotplug().
+* Just wake up the requestors. */
spin_lock_irq(rq-lock);
while (!list_empty(rq-migration_queue)) {
migration_req_t *req;
Index: 2.6.11-rc1+/kernel/stop_machine.c
===
--- 2.6.11-rc1+.orig/kernel/stop_machine.c 2005-01-16 23:15:30.0
+0100
+++ 2.6.11-rc1+/kernel/stop_machine.c 2005-01-18 19:55:25.0 +0100
@@ -195,13 +195,13
[RFC][PATCH 3/4] use a rwsem for cpucontrol
Currently, lock_cpu_hotplug serializes multiple calls to cpufreq-target()
on multiple CPUs even though that's unnecessary. Even further, it
serializes these calls with totally unrelated other parts of the kernel...
some ppc64 event reporting, some cache management, and so on. In my opinion
locking should be done subsystem (and normally data-)specific, and disabling
CPU hotplug should just do that.
This patch converts the semaphore cpucontrol to be a rwsem which allows us
to use it for _both_ variants: locking (write) and (multiple) other parts
disabling CPU hotplug (read).
Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
---
include/linux/cpu.h | 18 ++
kernel/cpu.c| 14 +++---
2 files changed, 21 insertions(+), 11 deletions(-)
Index: 2.6.11-rc1+/include/linux/cpu.h
===
--- 2.6.11-rc1+.orig/include/linux/cpu.h2005-01-16 23:15:30.0
+0100
+++ 2.6.11-rc1+/include/linux/cpu.h 2005-01-18 19:36:47.0 +0100
@@ -23,6 +23,7 @@
#include linux/node.h
#include linux/compiler.h
#include linux/cpumask.h
+#include linux/rwsem.h
#include asm/semaphore.h
struct cpu {
@@ -59,10 +60,17 @@
#ifdef CONFIG_HOTPLUG_CPU
/* Stop CPUs going up and down. */
-extern struct semaphore cpucontrol;
-#define lock_cpu_hotplug() down(cpucontrol)
-#define unlock_cpu_hotplug() up(cpucontrol)
-#define lock_cpu_hotplug_interruptible() down_interruptible(cpucontrol)
+extern struct rw_semaphore cpucontrol;
+/* these just disable CPU hotplug events but don't
+ * serialize following code */
+#define disable_cpu_hotplug() down_read(cpucontrol)
+#define enable_cpu_hotplug() up_read(cpucontrol)
+
+/* these disable CPU hotplug events _and_ serialize
+ * any following code */
+#define lock_cpu_hotplug() down_write(cpucontrol)
+#define unlock_cpu_hotplug() up_write(cpucontrol)
+#define lock_cpu_hotplug_interruptible() down_write_interruptible(cpucontrol)
#define hotcpu_notifier(fn, pri) { \
static struct notifier_block fn##_nb = \
{ .notifier_call = fn, .priority = pri }; \
@@ -71,6 +79,8 @@
int cpu_down(unsigned int cpu);
#define cpu_is_offline(cpu) unlikely(!cpu_online(cpu))
#else
+#define disable_cpu_hotplug() do { } while (0)
+#define enable_cpu_hotplug() do { } while (0)
#define lock_cpu_hotplug() do { } while (0)
#define unlock_cpu_hotplug() do { } while (0)
#define lock_cpu_hotplug_interruptible() 0
Index: 2.6.11-rc1+/kernel/cpu.c
===
--- 2.6.11-rc1+.orig/kernel/cpu.c 2005-01-16 23:15:30.0 +0100
+++ 2.6.11-rc1+/kernel/cpu.c2005-01-18 19:33:34.0 +0100
@@ -16,7 +16,7 @@
#include asm/semaphore.h
/* This protects CPUs going up and down... */
-DECLARE_MUTEX(cpucontrol);
+DECLARE_RWSEM(cpucontrol);
static struct notifier_block *cpu_chain;
@@ -25,19 +25,19 @@
{
int ret;
- if ((ret = down_interruptible(cpucontrol)) != 0)
+ if ((ret = down_write_interruptible(cpucontrol)) != 0)
return ret;
ret = notifier_chain_register(cpu_chain, nb);
- up(cpucontrol);
+ up_write(cpucontrol);
return ret;
}
EXPORT_SYMBOL(register_cpu_notifier);
void unregister_cpu_notifier(struct notifier_block *nb)
{
- down(cpucontrol);
+ down_write(cpucontrol);
notifier_chain_unregister(cpu_chain, nb);
- up(cpucontrol);
+ up_write(cpucontrol);
}
EXPORT_SYMBOL(unregister_cpu_notifier);
@@ -159,7 +159,7 @@
int ret;
void *hcpu = (void *)(long)cpu;
- if ((ret = down_interruptible(cpucontrol)) != 0)
+ if ((ret = down_write_interruptible(cpucontrol)) != 0)
return ret;
if (cpu_online(cpu) || !cpu_present(cpu)) {
@@ -188,6 +188,6 @@
if (ret != 0)
notifier_call_chain(cpu_chain, CPU_UP_CANCELED, hcpu);
out:
- up(cpucontrol);
+ up_write(cpucontrol);
return ret;
}
-
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: [BUG?]: cpufreqency scaling - wrong frequency detected
Hi, I hope this information can help you. I don't know if it's really a bug, yes, this seems to be a bug. so I send it to the mailing list instead of reporting it to the bugzilla bugtracking system. if you need additional information, I'll compile a Kernel with cpufreq debugging. Unfortunately, this seems to be necessary. Please re-compile with cpufreq debugging enabled, pass cpufreq.debug=2 on the kernel boot line, and send me the dmesg (off-list). Thanks, Dominik - 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.13-rc7: crash on removing CF card
Hi, On Thu, Aug 25, 2005 at 11:48:46AM +0200, Pavel Machek wrote: Something went wrong with PCMCIA on this X32. I inserted CF card, but it detected both hde *and* hdf, mount took forever. At that point I decided that I want my CF card back, took it back, it started producing different I/O errors , and then it oopsed. Did this happen also with 2.6.13-rc[3-6]? Thanks, Dominik - 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: [PATCH] acpi-cpufreq: Remove P-state read after a P-state write in normal path
Hi, On Fri, Aug 26, 2005 at 05:10:52PM -0700, Venkatesh Pallipadi wrote: /* - * Then we read the 'status_register' and compare the value with the - * target state's 'status' to make sure the transition was successful. - * Note that we'll poll for up to 1ms (100 cycles of 10us) before - * giving up. + * Assume the write went through when acpi_pstate_strict is not used. + * As read status_register is an expensive operation and there + * are no specific error cases where an IO port write will fail. */ Well, the IO port write itself might not fail, but the transition itself -- and we're reading the _status_ register here, not the control register where we've written to. And 8.4.4.1 of ACPI-sepc 3.0 does specifically mention that transitions _can_ fail, so I think we should handle this possibility. Dominik - 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: [PATCH] acpi-cpufreq: Remove P-state read after a P-state write in normal path
Hi, On Mon, Aug 29, 2005 at 11:03:57AM -0700, Venkatesh Pallipadi wrote: Yes. ACPI spec says transitions can fail. But, it doesn't fail often in practise. And even if it fails, I think, we should handle it without this read os STATUS register. How can we handle it, if we do not even know that it failed? How should the user recognize something is broken? The speedstep-centrino driver, which does similar thing as acpi-cpufreq, does not do this status check after control MSR write. We can skip the read of STATUS in cpi-cpufreq in a similar way. No? Well, regarding speedstep-centrino, it is news to me that the MSR write can fail... if it can fail, we should check for it. And reading the STATUS in a loop should go away. I don't see that it being mentioned in ACPI spec. The 1mS loop seems totally redundant. It looks to me as somebody had experienced that the transition only succeeded after waiting for some time. But well, as you do know the ACPI spec better than I do, I'll accept your evaluation that this patch won't cause any trouble. Dominik - 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: [PATCH] MPC8xx PCMCIA driver
Hi,
On Mon, Aug 29, 2005 at 11:48:40PM -0300, Marcelo Tosatti wrote:
Russell: The driver is using pccard_nonstatic_ops for card window
management, even though the driver its marked SS_STATIC_MAP (using
mem-static_map).
This is obviously broken. Where does it fail if pccard_static_ops is used?
+typedef struct {
+ u_int regbit;
+ u_int eventbit;
+} event_table_t;
No typedefs, please.
Dominik
-
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: PowerOP 0/3: System power operating point management API
Hi!
The PowerOP infrastructure you suggest surely is one path to better runtime
power management in the Linux kernel. However, I don't like it at all in its
current implementation. Here are a few suggestions for improvements,
rewrites, and so on:
First, the table interface you suggest is ugly. If there's indeed the need for
such an abstraction, I'd favour something like
struct powerop {
struct list_headpowerop_values; /* linked list of
powerop_values */
...
}
struct powerop_value {
unsigned long value_cur;
unsigned long value_min;
unsigned long value_max;
struct list_headnext;
u16 type;
struct powerop_value*cross_dependency;
struct powerop_driver *driver;
}
#define POWEROP_TYPE_CPU_FREQUENCY 0x0001
#define POWEROP_TYPE_CPU_VOLTAGE0x0002
#define POWEROP_TYPE_FRONT_SIDE_BUS_SPEED 0x0004
...
#define POWEROP_TYPE_GPU_FREQUENCY 0x0001
...
and if CPU_VOLTAGE and CPU_FREQEUNCY can only be modified at the same time, (as
most cpufreq drivers require), type is 0x0003.
Secondly, you do not adress the cross-relationships between operation points
correctly. If you change the CPU frequency, you may have to switch other
(memory, video) settings; you might even have to validate the frequency
settings for these or even additional reasons (thermal and battery reasons -
ACPI _PPC).
Thirdly, who is to decide on the power management settings? The first and
intuitive answer is the kernel. Therefore, kernel-space cpufreq governors
exist. Only under rare circumstances, you want full userspace control --
that's what the userspace cpufreq governor is for.
Foruthly, the code duplication which your implementation leads to is obvious
for the speedstep-centrino case. And in contrast to Pavel, I do not consider
it a tiny cleanup.
I'd suggest that you try upgrading the cpufreq infrastructure to provide
full support for multiple types of POWEROPs:
a) Setting of policies
- New min or max values for all powerop_values are set, verified
by powerop lowlevel drivers, powerop governors and external
notifiers. E.g. if a new frequency min/max pair is required, the
voltage level gets a new min and max value as well -- you need to
handle recursion.
- If necessary a new powerop governor is started.
- Each powerop governor specifies which POWEROPs it can handle
- current cpufreq governors can handle CPU_FREQUENCY,
CPU_VOLTAGE and FRONT_SIDE_BUS_SPEED
- an userspace fallback-governor always handles the
parameters no other governor handles
b) Setting of values
- Each governor can initiate transitions between the min and max
values for operationg points it aquired ownership for.
- The new setting is notified to all other governors and to external
notifiers. If some entitiy decides it cannot live well with this
new setting, it breaks out. Note that this should not happen quite
often, as the normal verification takes place in a) above.
Nonetheless, if you want to break out CPU_VOLTAGE and CPU_FREQUENCY,
you
need it. And as it makes life for the kernel so much more
difficult, I'm against doing so.
- The low-level driver handling the powerop_value is called
Thanks,
Dominik
-
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: PowerOP 0/3: System power operating point management API
A small add-on: We need to make sure that we're capable of handling smart CPUs like Transmeta Crusoe processors in a sane way. This means b)Setting of values is optional if the hardware itself can be set to a min/max value (step a above in previous mail). Dominik - 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: [PATCH 8/8] pci and yenta: pcibios_bus_to_resource
On Tue, Jul 26, 2005 at 04:50:49PM -0700, Greg KH wrote: On Tue, Jul 12, 2005 at 12:21:38AM +0200, Dominik Brodowski wrote: In yenta_socket, we default to using the resource setting of the CardBus bridge. However, this is a PCI-bus-centric view of resources and thus needs to be converted to generic resources first. Therefore, add a call to pcibios_bus_to_resource() call in between. This function is a mere wrapper on x86 and friends, however on some others it already exists, is added in this patch (alpha, arm, ppc, ppc64) or still needs to be provided (parisc -- where is its pcibios_resource_to_bus() ?). Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Hm, I saw a few different patches here, and some odd complaints. Care to resend an updated version? AFAICS, Andrew has merged all fixes into this version: http://kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm3/broken-out/pci-and-yenta-pcibios_bus_to_resource.patch Thanks, Dominik - 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/
dpm_runtime_suspend and _resume()
dpm_runtime_suspend and _resume() would be quite useful for some PCMCIA tasks. However, they are only exported in drivers/base/power/power.h. Any objection to moving it to include/linux/pm.h ? Any plans to break the functionality these functions provide? Thanks, Dominik - 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: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)
Hi, On Sun, Jul 31, 2005 at 12:30:30AM +0200, Pavel Machek wrote: Let me qualify that, because it's not 100% fine due to the changes in PCMCIA land. Since PCMCIA cards are detected and drivers bound at boot time, we no longer get hotplug events to setup networking for PCMCIA network cards already inserted. Consequently, if you are relying on /sbin/hotplug to setup your PCMCIA network card at boot time, triggered by the cardmgr startup binding the driver, it won't happen. Does that mean that if CF is inserted during bootup, it will simply appear as /dev/hda after bootup, without need to run cardmgr? Yes, which is almost a plus side. Whether you can use it to boot That's certainly a plus side, because I should be able to use pcmcia cards without setting much userland. Let me clarify this a bit, and point all interested parties to http://kernel.org/pub/linux/utils/kernel/pcmcia/howto.html PCMCIA can work without userspace on 2.6.13 if you compile all necessary things into the kernel and: a) the socket is smart enough.This is the case for - all sockets which statically map resources (hd64465, Au1x00, SA1100, SA, PXA2xx, M32R_PCC, M32R_CFC, VRC4171, VRC4173) - yenta-socket, pd6729 or i82092 if it 1) resides behind a PCI-PCI bridge [oh, I need to update the howto regarding this point...] or 2) resides behind some other bridge limiting the resource space (PPC, PPC64) and b) a Manufactor/Device or Product ID match is known for the device. Matching for Function ID (quite common for CF cards, unfortunately) is fuzzy and therefore can only be enabled if we are sure no (other) driver matches. And that's currently done by waiting for userspace telling the kernel that it already modprobed all available modules. In the long term, we should try to get rid of all Function ID matches, and use the more specific Manufactor, Device and Product ID matches. So patches adding more IDs are welcome. Thanks, Dominik - 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/
[PATCH] pcmcia: defer ide-cs initialization after other IDE drivers started up [Was: Re: Heads up for distro folks: PCMCIA hotplug differences (Re: -rc4: arm broken?)]
On Mon, Aug 01, 2005 at 07:48:31AM +0100, Russell King wrote: On Mon, Aug 01, 2005 at 02:01:07AM +0100, Alan Cox wrote: On Sad, 2005-07-30 at 22:36 +0100, Russell King wrote: Since PCMCIA cards are detected and drivers bound at boot time, we no longer get hotplug events to setup networking for PCMCIA network cards already inserted. Consequently, if you are relying on /sbin/hotplug to setup your PCMCIA network card at boot time, triggered by the cardmgr startup binding the driver, it won't happen. So eth0 now randomly changes between on board and PCMCIA depending upon whether the PCMCIA card was inserted or not, and your disks re-order themselves in the same situation. That'll be funny if anyone does a mkswap to share their swap between Linux and Windows. Gosh look there goes the root partition. I'm hoping thats not what you are implying. Especially for disks, network is much much less of an issue. If you have the socket driver as a module, as some (most?) distros do, then of course such cards won't be detected at boot time. If PCMCIA and the socket driver are built-in, along with the card driver, then I guess this possibility may well exist - it does for NE2K cards. Linus, Andrew, Please apply this for 2.6.13 - Thanks, Dominik Avoid registering PCMCIA CF cards before other IDE stuff. This means the risk of /dev/hd* being re-ordered is lessened. The _sane_ thing to assert any ordering is to use udev, nameif and so on, of course. Signed-off-by: Dominik Brodowski [EMAIL PROTECTED] Index: 2.6.13-rc4-git1/drivers/ide/legacy/ide-cs.c === --- 2.6.13-rc4-git1.orig/drivers/ide/legacy/ide-cs.c +++ 2.6.13-rc4-git1/drivers/ide/legacy/ide-cs.c @@ -508,5 +508,5 @@ static void __exit exit_ide_cs(void) BUG_ON(dev_list != NULL); } -module_init(init_ide_cs); +late_initcall(init_ide_cs); module_exit(exit_ide_cs); - 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: [PATCH] Obvious bugfix for yenta resource allocation
On Tue, Aug 02, 2005 at 09:51:36PM +1000, Paul Mackerras wrote: Recent changes (well, dating from 12 July) have broken cardbus on my powerbook: I get 3 messages saying no resource of type xxx available, trying to continue, and if I plug in my wireless card, it complains that there are no resources allocated to the card. This all worked in 2.6.12. Looking at the code in yenta_socket.c, function yenta_allocate_res, it's obvious what is wrong: if we get to line 639 (i.e. there wasn't a usable preassigned resource), we will always flow through to line 668, which is the printk that I was seeing, even if a resource was successfully allocated. It looks to me as though there should be a return statement after the two config_writel's in each of the 3 branches of the if statements, so that the function returns after successfully setting up the resource. The patch below adds these return statements, and with this patch, cardbus works on my powerbook once again. Signed-off-by: Paul Mackerras [EMAIL PROTECTED] Acked-by: Dominik Brodowski [EMAIL PROTECTED] Sorry for the bug. Dominik - 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: Linux 2.6.19
Hi, On Mon, Dec 11, 2006 at 03:47:58PM +0100, Romano Giannetti wrote: On Wed, 2006-11-29 at 14:21 -0800, Linus Torvalds wrote: You could send me and the kernel mailing list a note about it anyway, of course. (And perhaps pictures, if your dachshund is involved. Not that we'd be interested, of course. No. Just so that we'd know to avoid it next time). Hi most estimated kernel developers, I send this message to lobby for this to be included int the 2.16.20-rc1 http://lkml.org/lkml/2006/11/19/54 which fixed a regression for my PCMCIA modem (hey, it may qualify as a pet...) from the 2.6.13 age... details here: http://lists.infradead.org/pipermail/linux-pcmcia/2006-August/003893.html That's already in Linus' git tree. Moreover, I wish to signal it as a candidate for 2.6.19.y line. Regarding 2.6.19.y, that's on my TODO list. Dominik - 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: [patch] pipe: Don't oops when pipe filesystem isn't mounted
On Mon, Dec 11, 2006 at 06:08:22PM -0800, Andrew Morton wrote: diff --git a/include/linux/init.h b/include/linux/init.h index 5eb5d24..5a593a1 100644 --- a/include/linux/init.h +++ b/include/linux/init.h @@ -111,6 +111,7 @@ extern void setup_arch(char **); #define subsys_initcall_sync(fn) __define_initcall(4s,fn,4s) #define fs_initcall(fn)__define_initcall(5,fn,5) #define fs_initcall_sync(fn) __define_initcall(5s,fn,5s) +#define rootfs_initcall(fn) __define_initcall(rootfs,fn,rootfs) #define device_initcall(fn)__define_initcall(6,fn,6) #define device_initcall_sync(fn) __define_initcall(6s,fn,6s) #define late_initcall(fn) __define_initcall(7,fn,7) Looks like this might break pcmcia which for some reason does firmware requesting at fs_initcall level (drivers/pcmcia/ds.c). That codepath is not triggered before device_initcall()s occur. So it's a non-issue for PCMCIA. Thanks, Dominik - 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: Bug: Pentium M not always detected by CPUFREQ
On Wed, Nov 22, 2006 at 08:48:03AM +0100, Holger Schurig wrote: you don't have a pentium M In that case p4-clockmod has a bug, because it said that I have one. That bug should be fixed in -mm, cpufreq-git and 2.6.20. Thanks, Dominik - 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: [PATCH] PCMCIA identification strings for Elan -- second attempt
On Tue, Nov 21, 2006 at 01:58:31PM +, Tony Olech wrote: Hi, I can't find an actual device, and my former boss left Elan a few months ago, but I have attached the data from our product database: Thanks! Dominik - 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: [PATCH] PCMCIA identification strings for Elan -- second attempt
On Mon, Nov 20, 2006 at 01:04:39PM +, Tony Olech wrote: patch against linux kernel 2.6.18 to add PCMCIA identification strings From: Tony Olech [EMAIL PROTECTED] In older versions of the linux kernel it was sufficient for the 16-bit PCMCIA card manufacturer to distribute or make available a text configuration file along with the physical cards. Such a file with an extension of .conf and placed in the /etc/pcmcia very easily enabled new hardware without rebuilding the kernel, however with the new scheme of things, having found no userland solution to the problem of new 16bit pcmcia card identification this patch enumerates Elan Digital Systems strings. In addition, for the ID strings to result in the correct module being loaded, the too wide matching criterion of the PDaudioCF card needs to have the MANF_ID/CARD_ID numbers replaced by the more specific PROD_ID1 and PROD_ID2 strings. It is unfortunate that otherwise the pdaudiocf module is loaded whenever an ELAN pcmcia card is inserted, resulting in various random lockups Applied to pcmcia-2.6, thanks. Dominik - 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: PM-Timer clock source is slow. Try something else: How slow? What other source(s)?
On Thu, Nov 30, 2006 at 11:39:36AM -0800, Linda Walsh wrote: Srinivasa Ds wrote: You can change the clock source using clock= kernel parameter. Please refer to Documentation/kernel-parameters.txt file of kernel source. --- Uh, yeah...you mean the clock= parameter that is deprecated? :-) *cough* *sigh* clocksource= is the replacement. Dominik - 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 patch] drivers/pcmcia/m32r_cfc.c: fix compilation
On Sat, Dec 02, 2006 at 06:55:06PM +0100, Adrian Bunk wrote: More fallout of the post 2.6.19-rc1 IRQ changes... -- snip -- ... CC drivers/pcmcia/m32r_cfc.o In function 'pcc_interrupt_wrapper': /home/bunk/linux/kernel-2.6/linux-2.6.19-rc6-mm2/drivers/pcmcia/m32r_cfc.c:401: error: too many arguments to function 'pcc_interrupt' make[3]: *** [drivers/pcmcia/m32r_cfc.o] Error 1 -- snip -- Signed-off-by: Adrian Bunk [EMAIL PROTECTED] Applied, thanks. Dominik - 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/
[git pull] PCMCIA fixes for 2.6.19-rc6
Hej Linus, Please pull from git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-fixes-2.6.git/ The diffstat and list of changes follows; the patches will be sent out to the linux-pcmcia list and other relevant subsystem lists, if applicable. Thanks, Dominik drivers/ata/pata_pcmcia.c |2 drivers/char/pcmcia/cm4000_cs.c |6 - drivers/char/pcmcia/cm4040_cs.c |6 - drivers/ide/legacy/ide-cs.c |2 drivers/pcmcia/cs.c |7 - drivers/pcmcia/cs_internal.h|2 drivers/pcmcia/ds.c | 165 +++- drivers/pcmcia/pcmcia_ioctl.c |7 + drivers/pcmcia/pd6729.c |8 - drivers/pcmcia/socket_sysfs.c |4 include/pcmcia/ss.h |5 - 11 files changed, 125 insertions(+), 89 deletions(-) Akinobu Mita (1): cm4000_cs: fix return value check Dominik Brodowski (4): pcmcia: start over after CIS override pcmcia: multifunction card handling fixes pcmcia: fix 'rmmod pcmcia' with leftover devices pcmcia: handle __copy_from_user() return value in ioctl Komuro (1): pcmcia: allow shared IRQs on pd6729 sockets Marcin Juszkiewicz (1): pcmcia: yet another IDE ID Matt Reimer (1): pcmcia: Add an id to ide-cs.c - 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/
[git pull] PCMCIA changes for v4.2
Hi Linus, a few PCMCIA fixes and cleanups are available in the PCMCIA tree. Most of them are trivial and self-explanatory. Of particular note are the last three patches which add an important hardware quirk for Toshiba ToPIC95 sockets (or BIOS breakage on systems with these sockets), fix resource leaks in yenta_socket enable/disable call paths, and fix a regression caused by patch 1c6c9b1d9d25 since v4.0. Alan stated he is OK with me pushing this patch upstream; once it works out well in your tree, I will push it to stable for 4.0/4.1 as well. Therefore, please pull a few PCMCIA fixes and cleanups from: git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia.git master The following changes since commit aaa20fc23341be3df7b17810e330f12244abcf29: Merge tag 'acpi-pci-4.1-rc6' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm (2015-05-29 17:09:39 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia.git master for you to fetch changes up to e8e68fd86d22fa5bd9c7bed16043e27ac86998f8: pcmcia: do not break rsrc_nonstatic when handling anonymous cards (2015-06-16 07:29:39 +0200) Please pull from that location. The diffstat and list of changes is below, the individual diffs are sent (at least) to the linux-pcmcia list. Dominik Brodowski (1): pcmcia: do not break rsrc_nonstatic when handling anonymous cards Himangi Saraogi (3): pcmcia: Remove typedef tuple_flags pcmcia: Remove typedef in structs and emum pcmcia/vrc4171: Remove typedefs for enums and struct Jim Cromie (1): pcmcia: replace open-coded ARRAY_SIZE with macro Joe Perches (1): pcmcia: Convert dev_printk to dev_level Julia Lawall (1): drivers/pcmcia/electra_cf.c: add missing iounmap and kfree Laurent Navet (2): drivers: pcmcia: ds.c fix checkpatch errors drivers: pcmcia: electra_cf.c fix checkpatch error and warnings Robert P. J. Day (1): PCMCIA: Remove commented references to dead class_device_create_file() Ryan Underwood (1): Disable write buffering on Toshiba ToPIC95 Takeshi Yoshimura (1): pcmcia: Fix resource leaks in yenta_probe() and _close() drivers/char/pcmcia/cm4040_cs.c | 5 +-- drivers/pcmcia/cistpl.c | 50 - drivers/pcmcia/cs.c | 29 + drivers/pcmcia/ds.c | 76 ++-- drivers/pcmcia/electra_cf.c | 19 drivers/pcmcia/i82365.c | 43 -- drivers/pcmcia/m32r_cfc.c| 7 --- drivers/pcmcia/m32r_pcc.c| 7 --- drivers/pcmcia/pcmcia_cis.c | 4 +- drivers/pcmcia/pcmcia_resource.c | 11 ++--- drivers/pcmcia/rsrc_nonstatic.c | 44 +-- drivers/pcmcia/ti113x.h | 78 +++-- drivers/pcmcia/topic.h | 16 +++ drivers/pcmcia/vrc4171_card.c| 30 ++--- drivers/pcmcia/yenta_socket.c| 94 +--- 15 files changed, 249 insertions(+), 264 deletions(-) Thanks, Dominik signature.asc Description: Digital signature
Re: [PATCH 1/1] pcmcia: Add missing free_irq()
Hi Takeshi, On Sun, Jun 14, 2015 at 09:14:41PM +0900, Takeshi Yoshimura wrote: In yenta_probe(), an irq leak potentially happens when pcmcia_register_socket() fails. I added the missed call. nice catch, many thanks. index 965bd84..7922e30f 100644 --- a/drivers/pcmcia/yenta_socket.c +++ b/drivers/pcmcia/yenta_socket.c @@ -1269,6 +1269,8 @@ static int yenta_probe(struct pci_dev *dev, const struct pci_device_id *id) pcmcia_unregister_socket(socket-socket); } + if (socket-cb_irq) + free_irq(socket-irq, socket); unmap: iounmap(socket-base); release: However, this should also handle the case for sock-cb_irq being zero, like it is done in yenta_close. Furthermore, when comparing yenta_close and this error path in yenta_probe(), I noticed a few other issues: - yenta_free_resources() is not called in yenta_probe() - pci_set_drvdata(dev, NULL) and kfree(socket) are not called in yenta_probe() - sock-base is always set to non-NULL when yenta_close() is called, therefore the check in yenta_close() may be removed. Would you be willing to update your patch to address also these issues? Then, I'll happily push it upstream. Best, Dominik signature.asc Description: Digital signature
Re: [PATCH 4/5] pcmcia: handle anonymous cards by generating a fake CIS
On Thu, Dec 04, 2014 at 09:30:56PM +, Alan Cox wrote:
The core pcmcia code blows up all over the place if it allowed a card without
a valid CIS. We need to allow such cards as the CIS stuff is not on the older
flash, ROM and SRAM cards. We give it a suitably blank fake CIS instead.
In order to minimise the risk of misidentifying junk and feeding it to the
wrong thing we only fix up apparently anonymous cards if the driver for them
has been enabled.
Unfortunately, this patch does not work well with all of the callers of
pccard_validate_cis(). While it helps for ds.c:pcmcia_card_add() and does
not matter for cistpl.c:pccard_show_cis(), it breaks the callback in
rsrc_nonstatic.c:readable():
There, we test whether iomem resources actually work -- and we test this
by reading the CIS. This patch means that non-working resources are assumed
to work -- and the valid CIS is replaced with the fake CIS in this case.
Therefore, I'd suggest to move the override to the one place where it is
needed -- to ds.c:pcmcia_card_add(). A patch which implements this is below;
it fixes my test setup (which needs rsrc_nonstatic.c).
Alan, could you verify this patch helps with the use case you had in mind
when writing this patch? I inted to apply this patch to the PCMCIA tree only
after such testing.
Best,
Dominik
8-
pcmcia: do not break rsrc_nonstatic when handling anonymous cards
Patch 1c6c9b1d9d25 caused a regression for rsrc_nonstatic: It relies
on pccard_validate_cis() to determine whether an iomem resource can
be used for PCMCIA cards. This override, however, lead invalid iomem
resources to be accepted -- and lead to a fake CIS being used instead
of the original CIS.
To fix this issue, move the override for anonymous cards to the one
place where it is needed -- when adding a PCMCIA device.
CC: sta...@vger.kernel.org # for v4.0 and v4.1
Signed-off-by: Dominik Brodowski li...@dominikbrodowski.net
diff --git a/drivers/pcmcia/cistpl.c b/drivers/pcmcia/cistpl.c
index 64d0515..d15 100644
--- a/drivers/pcmcia/cistpl.c
+++ b/drivers/pcmcia/cistpl.c
@@ -1451,26 +1451,16 @@ int pccard_validate_cis(struct pcmcia_socket *s,
unsigned int *info)
done:
/* invalidate CIS cache on failure */
if (!dev_ok || !ident_ok || !count) {
-#if defined(CONFIG_MTD_PCMCIA_ANONYMOUS)
- /* Set up as an anonymous card. If we don't have anonymous
- memory support then just error the card as there is no
- point trying to second guess.
-
- Note: some cards have just a device entry, it may be
- worth extending support to cover these in future */
- if (!dev_ok || !ident_ok) {
- dev_info(s-dev, no CIS, assuming an anonymous memory
card.\n);
- pcmcia_replace_cis(s, \xFF, 1);
- count = 1;
- ret = 0;
- } else
-#endif
- {
- mutex_lock(s-ops_mutex);
- destroy_cis_cache(s);
- mutex_unlock(s-ops_mutex);
+ mutex_lock(s-ops_mutex);
+ destroy_cis_cache(s);
+ mutex_unlock(s-ops_mutex);
+ /* We differentiate between dev_ok, ident_ok and count
+ failures to allow for an override for anonymous cards
+ in ds.c */
+ if (!dev_ok || !ident_ok)
ret = -EIO;
- }
+ else
+ ret = -EFAULT;
}
if (info)
diff --git a/drivers/pcmcia/ds.c b/drivers/pcmcia/ds.c
index d3baf0b..e1498a0 100644
--- a/drivers/pcmcia/ds.c
+++ b/drivers/pcmcia/ds.c
@@ -634,8 +634,24 @@ static int pcmcia_card_add(struct pcmcia_socket *s)
ret = pccard_validate_cis(s, no_chains);
if (ret || !no_chains) {
- dev_dbg(s-dev, invalid CIS or invalid resources\n);
- return -ENODEV;
+#if defined(CONFIG_MTD_PCMCIA_ANONYMOUS)
+ /* Set up as an anonymous card. If we don't have anonymous
+ memory support then just error the card as there is no
+ point trying to second guess.
+
+ Note: some cards have just a device entry, it may be
+ worth extending support to cover these in future */
+ if (ret == -EIO) {
+ dev_info(s-dev, no CIS, assuming an anonymous memory
card.\n);
+ pcmcia_replace_cis(s, \xFF, 1);
+ no_chains = 1;
+ ret = 0;
+ } else
+#endif
+ {
+ dev_dbg(s-dev, invalid CIS or invalid resources\n);
+ return -ENODEV;
+ }
}
if (!pccard_read_tuple(s, BIND_FN_ALL, CISTPL_LONGLINK_MFC, mfc))
signature.asc
Description
Re: [PATCH 1/1] pcmcia: Fix resource leaks in yenta_probe() and _close()
On Mon, Jun 15, 2015 at 02:43:59AM +0900, Takeshi Yoshimura wrote: There are some resource leaks in yenta_probe() and _close(). I fixed the following issues with some code cleanups. Thanks to Dominik's suggestions. On the error path in yenta_probe(): - a requested irq is not released - yenta_free_resources() and pci_set_drvdata(dev, NULL) are not called In yenta_close(): - kfree(sock) is not called - sock-base is always set to non-NULL when yenta_close() is called, therefore the check in yenta_close() is not necessary. Signed-off-by: Takeshi Yoshimura y...@sslab.ics.keio.ac.jp Applied to the PCMCIA tree. Many thanks! Dominik signature.asc Description: Digital signature
Re: [PATCH 4/5] pcmcia: handle anonymous cards by generating a fake CIS
On Mon, Jun 15, 2015 at 01:10:55PM +0100, Alan Cox wrote: Unfortunately, this patch does not work well with all of the callers of pccard_validate_cis(). While it helps for ds.c:pcmcia_card_add() and does not matter for cistpl.c:pccard_show_cis(), it breaks the callback in rsrc_nonstatic.c:readable(): I'm not sure it's the right way to do readable() but we seem to be stuck with that anyway. Indeed - any replacement would need much testing at least. The change looks good to me, and I will try and test it soon but it may take some time due to various other things going on in life. Can you submit it for 4.2 anyway and give it a bit of time for any screaming then push to stable ? Have added it to my tree, and will do as you suggest. Thanks, Dominik -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Disable write buffering on Toshiba ToPIC95
Ryan,
thanks for this patch. Could you add a Signed-off-by line as specified in
Documentation/SubmittingPatches, please, so that I can pick it up and push
it upstream? Thanks!
Dominik
On Sun, Jan 25, 2015 at 04:07:09PM -0800, Ryan C. Underwood wrote:
From: Ryan Underwood neme...@icequake.net
Disable write buffering on the Toshiba ToPIC95 if it is enabled by somebody
(it
is not supposed to be a power-on default according to the datasheet). On the
ToPIC95, practically no 32-bit Cardbus card will work under heavy load without
locking up the whole system if this is left enabled. I tried about a dozen.
It does not affect 16-bit cards. This is similar to the O2 bugs in early
controller revisions it seems. Originally posted to
https://bugzilla.kernel.org/show_bug.cgi?id=55961
---
drivers/pcmcia/topic.h | 16
1 file changed, 16 insertions(+)
diff --git a/drivers/pcmcia/topic.h b/drivers/pcmcia/topic.h
index 615a45a..582688fe 100644
--- a/drivers/pcmcia/topic.h
+++ b/drivers/pcmcia/topic.h
@@ -104,6 +104,9 @@
#define TOPIC_EXCA_IF_CONTROL0x3e/* 8 bit */
#define TOPIC_EXCA_IFC_33V_ENA 0x01
+#define TOPIC_PCI_CFG_PPBCN 0x3e/* 16-bit */
+#define TOPIC_PCI_CFG_PPBCN_WBEN 0x0400
+
static void topic97_zoom_video(struct pcmcia_socket *sock, int onoff)
{
struct yenta_socket *socket = container_of(sock, struct yenta_socket,
socket);
@@ -138,6 +141,7 @@ static int topic97_override(struct yenta_socket *socket)
static int topic95_override(struct yenta_socket *socket)
{
u8 fctrl;
+ u16 ppbcn;
/* enable 3.3V support for 16bit cards */
fctrl = exca_readb(socket, TOPIC_EXCA_IF_CONTROL);
@@ -146,6 +150,18 @@ static int topic95_override(struct yenta_socket *socket)
/* tell yenta to use exca registers to power 16bit cards */
socket-flags |= YENTA_16BIT_POWER_EXCA | YENTA_16BIT_POWER_DF;
+ /* Disable write buffers to prevent lockups under load with numerous
+Cardbus cards, observed on Tecra 500CDT and reported elsewhere on the
+net. This is not a power-on default according to the datasheet
+but some BIOSes seem to set it. */
+ if (pci_read_config_word(socket-dev, TOPIC_PCI_CFG_PPBCN, ppbcn) == 0
+ socket-dev-revision = 7
+ (ppbcn TOPIC_PCI_CFG_PPBCN_WBEN)) {
+ ppbcn = ~TOPIC_PCI_CFG_PPBCN_WBEN;
+ pci_write_config_word(socket-dev, TOPIC_PCI_CFG_PPBCN, ppbcn);
+ dev_info(socket-dev-dev, Disabled ToPIC95 Cardbus write
buffers.\n);
+ }
+
return 0;
}
--
1.9.1
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
signature.asc
Description: Digital signature
Re: [PATCH 5/5] pcmcia: add a new resource manager for non ISA systems
Alan, On Thu, Dec 04, 2014 at 09:31:22PM +, Alan Cox wrote: On a pure PCI platform we don't actually need all the complexity of the rsrc_nonstatic manager, in fact we can just work directly with the pci allocators and avoid all the complexity (and code bloat). I know you're re-working this thing by now, but still: Can we be certain that BIOS, ACPI etc. properly report all io resources which must not be utilized by other devices? Does this really depend on ISA being set in Kconfig? Should this also be enabled for CardBus bridges on the root PCI bus? And: could doing a check for X86 like in rsrc_nonstatic.c ( avoid anything 0x100 for ioports ) help to avoid some of the possible fallout? Best, Dominik signature.asc Description: Digital signature
Re: [PATCH 27/43] MAINTAINERS: update git URL for PCMCIA
On Fri, Dec 18, 2015 at 03:51:50PM +0800, Fengguang Wu wrote: > CC: linux-pcm...@lists.infradead.org > CC: Dominik Brodowski <li...@dominikbrodowski.net> > Signed-off-by: Fengguang Wu <fengguang...@intel.com> Acked-by: Dominik Brodowski <li...@dominikbrodowski.net> Thanks! Dominik > --- > MAINTAINERS |2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > --- linux.orig/MAINTAINERS2015-12-18 15:43:29.233016928 +0800 > +++ linux/MAINTAINERS 2015-12-18 15:43:29.229016928 +0800 > @@ -8285,7 +8285,7 @@ PCMCIA SUBSYSTEM > P: Linux PCMCIA Team > L: linux-pcm...@lists.infradead.org > W: http://lists.infradead.org/mailman/listinfo/linux-pcmcia > -T: git git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia-2.6.git > +T: git git://git.kernel.org/pub/scm/linux/kernel/git/brodo/pcmcia.git > S: Maintained > F: Documentation/pcmcia/ > F: drivers/pcmcia/ > > signature.asc Description: Digital signature
Re: [RFC][PATCH 4/7] cpufreq / sched: Add flags argument to cpufreq_update_util()
On Mon, Aug 01, 2016 at 01:36:46AM +0200, Rafael J. Wysocki wrote: > +#define UUF_RT 0x01 What does UUF stand for? Best Dominik
