Alex Dubov wrote:
I prepared a tarball with 2.6.21 compatible driver (tifm-0.8e on berlios).
This is "good enough" to withdraw my patch. I have filed it to
http://bugzilla.kernel.org/attachment.cgi?id=11312=view
in bug 8052
http://bugzilla.kernel.org/show_bug.cgi?id=8052
which seems to be
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sergey Yanovich wrote:
> > I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
> > After [tifm_sd] is loaded. My smoke test script at
> >
> > http://bugzilla.kernel.org/attachment.cgi?id=11240=view
> >
> > reliably hangs suspend.
>
> I
Sergey Yanovich wrote:
> I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
> After [tifm_sd] is loaded. My smoke test script at
>
> http://bugzilla.kernel.org/attachment.cgi?id=11240=view
>
> reliably hangs suspend.
I really wish you would stop removing me from cc...
Suspend is
Can you successfully run this test with -mm tree? I that case
the fault may be hardware related.
I have uploaded an updated version to bugzilla:
http://bugzilla.kernel.org/attachment.cgi?id=11308=view
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
What is "modprobe tifm"?
tifm is the name of the "monolithic blob" that I test :).
What modules have you loaded when it hangs?
I believe is the relevant part:
~$ lsmod | grep "mmc\|tifm"
tifm_sd11272 0
mmc_core 25812 1 tifm_sd
tifm_7xx1 6848 0
> After [tifm_sd] is loaded. My smoke test script at
>
> http://bugzilla.kernel.org/attachment.cgi?id=11240=view
>
> reliably hangs suspend.
>
What is "modprobe tifm"? What modules have you loaded when it hangs?
__
Do You Yahoo!?
Tired of spam?
After [tifm_sd] is loaded. My smoke test script at
http://bugzilla.kernel.org/attachment.cgi?id=11240action=view
reliably hangs suspend.
What is modprobe tifm? What modules have you loaded when it hangs?
__
Do You Yahoo!?
Tired of spam?
What is modprobe tifm?
tifm is the name of the monolithic blob that I test :).
What modules have you loaded when it hangs?
I believe is the relevant part:
~$ lsmod | grep mmc\|tifm
tifm_sd11272 0
mmc_core 25812 1 tifm_sd
tifm_7xx1 6848 0
Can you successfully run this test with -mm tree? I that case
the fault may be hardware related.
I have uploaded an updated version to bugzilla:
http://bugzilla.kernel.org/attachment.cgi?id=11308action=view
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a
Sergey Yanovich wrote:
I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
After [tifm_sd] is loaded. My smoke test script at
http://bugzilla.kernel.org/attachment.cgi?id=11240action=view
reliably hangs suspend.
I really wish you would stop removing me from cc...
Suspend is
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Sergey Yanovich wrote:
I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
After [tifm_sd] is loaded. My smoke test script at
http://bugzilla.kernel.org/attachment.cgi?id=11240action=view
reliably hangs suspend.
I really
Alex Dubov wrote:
I prepared a tarball with 2.6.21 compatible driver (tifm-0.8e on berlios).
This is good enough to withdraw my patch. I have filed it to
http://bugzilla.kernel.org/attachment.cgi?id=11312action=view
in bug 8052
http://bugzilla.kernel.org/show_bug.cgi?id=8052
which seems to be
Alex Dubov wrote:
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree - too many
changes are committed into it. The -mm version obviously fits its tree.
I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
After [tifm_sd] is loaded. My smoke test
> It seems a bit out-of-date. Here is the output:
>
It clearly says there that the driver is for 2.6.20. The changes needed for
2.6.21 are actually
very small (couple of fields in the mmc layer were renamed).
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
problems with it, I'll be glad to fix them.
The version in question was recently committed into the -mm tree. Otherwise,
it's available from
the project's website for a couple of months now:
It
>
> I have submitted my version only after I have failed to find a stable
> version of your driver for the current kernel. If there is one, just
> post link to the patch. If not, let's make one.
>
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
Alex Dubov wrote:
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step him. Drivers are rarely complex enough to warrant, or even have room for, a
rewrite. And judging from your code it
Alex Dubov wrote:
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step him. Drivers are rarely complex enough to warrant, or even have room for, a
rewrite. And judging from your code it
I have submitted my version only after I have failed to find a stable
version of your driver for the current kernel. If there is one, just
post link to the patch. If not, let's make one.
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
problems
As I already said, I'm not aware of any issues with version 0.8 of the driver.
If you have any
problems with it, I'll be glad to fix them.
The version in question was recently committed into the -mm tree. Otherwise,
it's available from
the project's website for a couple of months now:
It
It seems a bit out-of-date. Here is the output:
It clearly says there that the driver is for 2.6.20. The changes needed for
2.6.21 are actually
very small (couple of fields in the mmc layer were renamed).
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree -
Alex Dubov wrote:
In general, it is impossible to maintain out-of-tree driver in sync with kernel
tree - too many
changes are committed into it. The -mm version obviously fits its tree.
I have compiled v2.6.21 with git-mmc.patch of v2.6.21-rc7.mm2.
After [tifm_sd] is loaded. My smoke test
--- Pierre Ossman <[EMAIL PROTECTED]> wrote:
> Sergey Yanovich wrote:
> >
> > I have found it easier to rewrite the driver, than to fix.
>
> Before you get your hopes up, this development model is not one that will get
> your code merged upstream. You should really try to work with Alex, not
Sergey Yanovich wrote:
>
> I have found it easier to rewrite the driver, than to fix.
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step him. Drivers are rarely complex enough to warrant,
Sergey Yanovich wrote:
I have found it easier to rewrite the driver, than to fix.
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step him. Drivers are rarely complex enough to warrant,
--- Pierre Ossman [EMAIL PROTECTED] wrote:
Sergey Yanovich wrote:
I have found it easier to rewrite the driver, than to fix.
Before you get your hopes up, this development model is not one that will get
your code merged upstream. You should really try to work with Alex, not side
step
Hi,
If you add support for let's say [tifm_8xx2] in the future, which
would have port offsets different that [tifm_7xx1], you would also need a
completely new modules for slots (sd, ms, etc).
Does not this constitutes an unbounded speculation?
Only time will tell :)
And then, what would you
Hi,
If you add support for let's say [tifm_8xx2] in the future, which
would have port offsets different that [tifm_7xx1], you would also need a
completely new modules for slots (sd, ms, etc).
Does not this constitutes an unbounded speculation?
Only time will tell :)
And then, what would you
>
> I am not in any way argue that your driver architecture is wrong or that you
> should change anything. My point was simple. [tifm_sd] can only work with
> [tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
> would have port offsets different that [tifm_7xx1], you
SUBSYSTEM=="tifm", ACTION=="add", TIFM_CARD_TYPE=="SD", RUN+="/sbin/modprobe
tifm_sd"
Thanks.
As a side note: I have some very good reasons for the current driver
architecture. You may want to
look them up in the mail archive (I outlined them during the initial driver
submission).
I am
--- Sergey Yanovich <[EMAIL PROTECTED]> wrote:
> > > For a typical, non-linux-geek user there are just two states of the
> > > device -
> > > available and not available. Ububtu is famous for its end-user support.
> > > They ship your driver since linux-2.6.17. But they pack it in one module.
>
> For a typical, non-linux-geek user there are just two states of the device -
> available and not available. Ububtu is famous for its end-user support.
> They ship your driver since linux-2.6.17. But they pack it in one module.
> And that is _much_ easier, then a hotplug script.
No, we ship a
On Sun, Apr 22, 2007 at 03:15:22PM +0300, Sergey Yanovich wrote:
> For a typical, non-linux-geek user there are just two states of the device -
> available and not available. Ububtu is famous for its end-user support.
> They ship your driver since linux-2.6.17. But they pack it in one module.
>
On Sun, Apr 22, 2007 at 03:15:22PM +0300, Sergey Yanovich wrote:
For a typical, non-linux-geek user there are just two states of the device -
available and not available. Ububtu is famous for its end-user support.
They ship your driver since linux-2.6.17. But they pack it in one module.
And
For a typical, non-linux-geek user there are just two states of the device -
available and not available. Ububtu is famous for its end-user support.
They ship your driver since linux-2.6.17. But they pack it in one module.
And that is _much_ easier, then a hotplug script.
No, we ship a udev
--- Sergey Yanovich [EMAIL PROTECTED] wrote:
For a typical, non-linux-geek user there are just two states of the
device -
available and not available. Ububtu is famous for its end-user support.
They ship your driver since linux-2.6.17. But they pack it in one module.
And that is
SUBSYSTEM==tifm, ACTION==add, TIFM_CARD_TYPE==SD, RUN+=/sbin/modprobe
tifm_sd
Thanks.
As a side note: I have some very good reasons for the current driver
architecture. You may want to
look them up in the mail archive (I outlined them during the initial driver
submission).
I am not in
I am not in any way argue that your driver architecture is wrong or that you
should change anything. My point was simple. [tifm_sd] can only work with
[tifm_7xx1]. If you add support for let's say [tifm_8xx2] in the future, which
would have port offsets different that [tifm_7xx1], you would
Hi,
> Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
It would be nice
Hi,
Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
It would be nice
> Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
As I already said before,
Finally, tifm_sd module needs to be manually inserted.
By the way, the driver emits custom uevent when the new card is detected. I was
going to look at
this some day in the future, but if you want to mess a little with hotplug
scripts the issue can
be easily solved.
As I already said before,
Hi,
> Have you looked at the last version (0.8)? It fixed all outstanding
issues (as far as I know).
>
Seconded. I've been running Alex's latest driver since its release. I
routinely suspend/resume
60-100 times between boots to S3 and disk, I've suspended with cards
in the socket and I've
Hi,
Arnd Bergmann wrote:
As very general comments, you should have the maintainer of the subsystem
(Pierre in this case) on Cc when posting a driver, and you should include
the patch inline in your mail, see Documentation/SubmittingPatches.
I have cc'ed both Pierre and Alex, but my first
+1
On 4/20/07, Brad Campbell <[EMAIL PROTECTED]> wrote:
Alex Dubov wrote:
> Have you looked at the last version (0.8)? It fixed all outstanding issues
(as far as I know).
>
Seconded. I've been running Alex's latest driver since its release. I routinely
suspend/resume
60-100 times between
Alex Dubov wrote:
Have you looked at the last version (0.8)? It fixed all outstanding issues (as
far as I know).
Seconded. I've been running Alex's latest driver since its release. I routinely suspend/resume
60-100 times between boots to S3 and disk, I've suspended with cards in the socket
Alex Dubov wrote:
Have you looked at the last version (0.8)? It fixed all outstanding issues (as
far as I know).
Seconded. I've been running Alex's latest driver since its release. I routinely suspend/resume
60-100 times between boots to S3 and disk, I've suspended with cards in the socket
+1
On 4/20/07, Brad Campbell [EMAIL PROTECTED] wrote:
Alex Dubov wrote:
Have you looked at the last version (0.8)? It fixed all outstanding issues
(as far as I know).
Seconded. I've been running Alex's latest driver since its release. I routinely
suspend/resume
60-100 times between boots
Hi,
Arnd Bergmann wrote:
As very general comments, you should have the maintainer of the subsystem
(Pierre in this case) on Cc when posting a driver, and you should include
the patch inline in your mail, see Documentation/SubmittingPatches.
I have cc'ed both Pierre and Alex, but my first
Hi,
Have you looked at the last version (0.8)? It fixed all outstanding
issues (as far as I know).
Seconded. I've been running Alex's latest driver since its release. I
routinely suspend/resume
60-100 times between boots to S3 and disk, I've suspended with cards
in the socket and I've
Have you looked at the last version (0.8)? It fixed all outstanding issues (as
far as I know).
--- Sergey Yanovich <[EMAIL PROTECTED]> wrote:
-
Hi,
The device is present in many notebooks. Notebooks depend heavily
onsuspend/resume functionality.
On Thursday 19 April 2007, Sergey Yanovich wrote:
> The device is present in many notebooks. Notebooks depend heavily on
> suspend/resume functionality. tifm_core/7xx1/sd family is an ambitous,
> but uncompleted project. It used to crash on resuming, or hang up on
> suspending. A less common
On Thursday 19 April 2007, Sergey Yanovich wrote:
The device is present in many notebooks. Notebooks depend heavily on
suspend/resume functionality. tifm_core/7xx1/sd family is an ambitous,
but uncompleted project. It used to crash on resuming, or hang up on
suspending. A less common
Have you looked at the last version (0.8)? It fixed all outstanding issues (as
far as I know).
--- Sergey Yanovich [EMAIL PROTECTED] wrote:
-
Hi,
The device is present in many notebooks. Notebooks depend heavily
onsuspend/resume functionality.
54 matches
Mail list logo
