lkml.org 
[lkml]   [2004]   [Jul]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH] driver model and sysfs support for PCMCIA (1/3)
Hi Adam,

On Mon, Jul 05, 2004 at 10:47:04PM +0000, Adam Belay wrote:
> > - I like many ideas in your patches -- large parts of them, though, are
> > "double work" as similar things have already been submitted (by me)
> > to Russell on the linux-pcmcia mailing list. What's missing in my current
> > patches [proof-of-concepts do exist and had been announced both on lkml
> > and on said linux-pcmcia list, though] is the exporting of product and
> > manufactor ID and "vers_1" strings, because that needs better resource
> > handling.
> > - the resource_ready handling is "racy", at least. Resources can disappear
> > again.
>
> Could you provide an example of how resources will disappear again?

/etc/pcmcia/config.opts may include

include memory 0xc0000-0xfffff
exclude memory 0xc0000-0xfffff

even though it wouldn't make sense.

> My patch
> was designed so that even if they weren't available, nothing bad would happen.
> Furthermore, it rescans for devices when userspace attempts to bind a driver.
> Resources would almost certainly be available during that time,

Indeed, they _are_ available during that time, else userspace wouldn't know
what driver to bind. That's why my approach registers the pcmcia "sysfs"
device struct at that place.

> In other
> words, it seems that resource handling is a problem for all of pcmcia.

It is, but partly because used ioports and iomem are not 100% accounted in
/proc/ioports and /proc/iomem. I'm eagerly awaiting the creation of a PNP-
and/or ACPI-based resource core "backend", like you proposed at Kernel
Summit last year, IIRC, which possibly allows the PCMCIA core on x86{,_64}
to "trust" the resources not in the resource database to be available for
PCMCIA's use.

> It was to add minimal support for a much needed feature while introducing
> as few potential bugs as possible to a stable kernel series. I see 2.7 as
> the time for rewrites. With that in mind, I consider your patches to be a
> great solution, but I'm worried about changing internal ds functionality
> during 2.6.

However, adding pcmcia devices at the place you suggest causes resource
headaches and makes merging my patches in 2.7. much more difficult. So,
could we work to a compromise patch where PCMCIA sysfs device structs are
only registered at "bind" time [as long as Russell agrees, that is...]?

Also, what do we need the "hotplug" export for? I'd like to avoid backwards
compatibility trouble in future, and as users _need_ to run cardmgr hotplug
seems to be without usage now.

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

\
 
 \ /
  Last update: 2005-03-22 14:04    [W:0.054 / U:0.676 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site