>From f1cd048a066b249082752a96abce7d33a0cd4ea3 Mon Sep 17 00:00:00 2001
From: Sergey Yanovich
Date: Tue, 21 May 2013 03:06:31 +0400
Subject: [PATCH] rtc-ds1302: handle write protection
This chip has a control register and can prevent altering saved clock.
Without this patch we could have:
--
On Wed, 2013-05-29 at 15:53 -0700, Andrew Morton wrote:
> On Tue, 21 May 2013 03:21:30 +0400 Sergey Yanovich wrote:
> @@ -321,6 +326,7 @@ static int ds1302_rtc_remove(struct platform_device *pdev)
> > {
> > struct rtc_device *rtc = platform_get_drvdata(pdev);
> >
On Wed, 2013-05-29 at 15:53 -0700, Andrew Morton wrote:
On Tue, 21 May 2013 03:21:30 +0400 Sergey Yanovich ynv...@gmail.com wrote:
@@ -321,6 +326,7 @@ static int ds1302_rtc_remove(struct platform_device *pdev)
{
struct rtc_device *rtc = platform_get_drvdata(pdev
From f1cd048a066b249082752a96abce7d33a0cd4ea3 Mon Sep 17 00:00:00 2001
From: Sergey Yanovich ynv...@gmail.com
Date: Tue, 21 May 2013 03:06:31 +0400
Subject: [PATCH] rtc-ds1302: handle write protection
This chip has a control register and can prevent altering saved clock.
Without this patch we
t.d/hwclock.sh stop
[info] Saving the system clock.
[info] Hardware Clock updated to Tue May 21 03:09:01 MSK 2013.
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:14:15 2013 -0.624272 seconds
8<
Signed-off-by: Sergey Yanovich
---
drivers/rtc/rtc-ds1302.c |6 ++
1 file c
/hwclock.sh stop
[info] Saving the system clock.
[info] Hardware Clock updated to Tue May 21 03:09:01 MSK 2013.
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:14:15 2013 -0.624272 seconds
8
Signed-off-by: Sergey Yanovich ynv...@gmail.com
---
drivers/rtc/rtc-ds1302.c |6 ++
1
On Sat, 2013-04-13 at 13:56 +0200, Ulf Hansson wrote:
>
> Den 13 apr 2013 12:49 skrev "Sergey Yanovich" :
> > A possible solution is to make card a separate device (now only the
> host
> > is a device). In this case, the probing could be done asynchronously
>
On Wed, 2013-03-27 at 07:57 -0400, Chris Ball wrote:
> If the delay's significant, I agree with you and will revert this patch.
The patch was reverted. The problem is back. Filed bug:
https://bugzilla.kernel.org/show_bug.cgi?id=56561
A possible solution is to make card a separate device (now
On Wed, 2013-03-27 at 07:57 -0400, Chris Ball wrote:
If the delay's significant, I agree with you and will revert this patch.
The patch was reverted. The problem is back. Filed bug:
https://bugzilla.kernel.org/show_bug.cgi?id=56561
A possible solution is to make card a separate device (now only
On Sat, 2013-04-13 at 13:56 +0200, Ulf Hansson wrote:
Den 13 apr 2013 12:49 skrev Sergey Yanovich ynv...@gmail.com:
A possible solution is to make card a separate device (now only the
host
is a device). In this case, the probing could be done asynchronously
without breaking
On Thu, 2013-04-04 at 14:35 +0300, Adrian Hunter wrote:
> On 04/04/13 13:59, Sergey Yanovich wrote:
> > On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
> >> No, I am booting from eMMC.
> >
> > Well, in this case you should be aware, that your system is no
On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
> No, I am booting from eMMC.
Well, in this case you should be aware, that your system is not
concurrency-safe without the patch. It may or may not boot each time
depending on the large number of factors.
> > Maybe introduce
On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
No, I am booting from eMMC.
Well, in this case you should be aware, that your system is not
concurrency-safe without the patch. It may or may not boot each time
depending on the large number of factors.
Maybe introduce
On Thu, 2013-04-04 at 14:35 +0300, Adrian Hunter wrote:
On 04/04/13 13:59, Sergey Yanovich wrote:
On Thu, 2013-04-04 at 09:35 +0300, Adrian Hunter wrote:
No, I am booting from eMMC.
Well, in this case you should be aware, that your system is not
concurrency-safe without the patch
On Tue, 2013-04-02 at 19:45 +0200, Ulf Hansson wrote:
> On 2 April 2013 12:35, Sergey Yanovich wrote:
> > If the system is booted using initrd and root is not on an mmc card,
> > then mmc modules can be omitted from initrd. The probing will happen
> > only
On Tue, 2013-04-02 at 16:36 +0300, Adrian Hunter wrote:
> On my system it is significant:
>
> Before the patch:
>
> [1.625623] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
>
> After the patch:
>
> [1.935851] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
On Tue, 2013-04-02 at 12:13 +0200, Ulf Hansson wrote:
> Consider a platform having two eMMCs and one SD-card. Each eMMC card
> will take around 400 ms to initialize and the SD-card 700 ms. The card
> initialization times are real examples from eMMCs and SD-cards,
> moreover those are typical
On Tue, 2013-04-02 at 12:13 +0200, Ulf Hansson wrote:
Consider a platform having two eMMCs and one SD-card. Each eMMC card
will take around 400 ms to initialize and the SD-card 700 ms. The card
initialization times are real examples from eMMCs and SD-cards,
moreover those are typical values
On Tue, 2013-04-02 at 16:36 +0300, Adrian Hunter wrote:
On my system it is significant:
Before the patch:
[1.625623] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
After the patch:
[1.935851] VFS: Mounted root (ext4 filesystem) readonly on device 179:2.
That
On Tue, 2013-04-02 at 19:45 +0200, Ulf Hansson wrote:
On 2 April 2013 12:35, Sergey Yanovich ynv...@gmail.com wrote:
If the system is booted using initrd and root is not on an mmc card,
then mmc modules can be omitted from initrd. The probing will happen
only after root is mounted
.
Signed-off-by: Sergey Yanovich
---
drivers/w1/Kconfig |7 ++
drivers/w1/Makefile |3 +-
drivers/w1/notify.c | 76
drivers/w1/w1.c |2 +
drivers/w1/w1.h | 160 --
drivers/w1/w1_int.c |2
.
Signed-off-by: Sergey Yanovich ynv...@gmail.com
---
drivers/w1/Kconfig |7 ++
drivers/w1/Makefile |3 +-
drivers/w1/notify.c | 76
drivers/w1/w1.c |2 +
drivers/w1/w1.h | 160 --
drivers/w1/w1_int.c
On 14/03/13 08:08, Namjae Jeon wrote:> 2013/3/14, Sergey Yanovich
:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Have you ever tried to use rootwait or rootdelay on command line ?
If no, You can use them.
Those options work. However, they introduce a de
On 14/03/13 06:47, Greg Kroah-Hartman wrote:
On Thu, Mar 14, 2013 at 05:06:23AM +0400, Sergey Yanovich wrote:
/* wait for the known devices to complete their probing */
-
wait_event(probe_waitqueue, atomic_read(_count) == 0);
You didn't need to change this file, please don't
On 14/03/13 06:47, Greg Kroah-Hartman wrote:
On Thu, Mar 14, 2013 at 05:06:23AM +0400, Sergey Yanovich wrote:
/* wait for the known devices to complete their probing */
-
wait_event(probe_waitqueue, atomic_read(probe_count) == 0);
You didn't need to change this file, please
On 14/03/13 08:08, Namjae Jeon wrote: 2013/3/14, Sergey Yanovich
ynv...@gmail.com:
Kernel panic - not syncing: VFS: Unable to mount root fs on
unknown-block(0,0)
Have you ever tried to use rootwait or rootdelay on command line ?
If no, You can use them.
Those options work. However
16384 mtdblock4 mmcblk0: mmc0:b368 USD 3.72 GiB
(driver?)
mmcblk0: p1
b300 3910656 mmcblk0 driver: mmcblk
b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8<---
Signed-off-by: Sergey Yanovich
---
changes f
16384 mtdblock4 mmcblk0: mmc0:b368 USD 3.72 GiB
(driver?)
mmcblk0: p1
b300 3910656 mmcblk0 driver: mmcblk
b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8<---
Signed-off-by: Sergey Yanovich
---
driv
3.8.2 ARM kernel panics on boot. BUG() log:
[ cut here ]
Kernel BUG at c0226bf4 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0Not tainted (3.8.2+ #2)
PC is at pxa2xx_flash_probe+0x150/0x1a8
LR is at
3.8.2 ARM kernel panics on boot. BUG() log:
[ cut here ]
Kernel BUG at c0226bf4 [verbose debug info unavailable]
Internal error: Oops - BUG: 0 [#1] PREEMPT ARM
Modules linked in:
CPU: 0Not tainted (3.8.2+ #2)
PC is at pxa2xx_flash_probe+0x150/0x1a8
LR is at
:b368 USD 3.72 GiB
(driver?)
mmcblk0: p1
b300 3910656 mmcblk0 driver: mmcblk
b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8---
Signed-off-by: Sergey Yanovich ynv...@gmail.com
---
drivers/base/dd.c
:b368 USD 3.72 GiB
(driver?)
mmcblk0: p1
b300 3910656 mmcblk0 driver: mmcblk
b301 3906560 mmcblk0p1 -01
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
---8---
Signed-off-by: Sergey Yanovich ynv...@gmail.com
---
changes for v2:
- removed
, PXA ports could be configured with different
name and device numbers.
Signed-off-by: Sergey Yanovich
---
drivers/tty/serial/Kconfig | 14 ++
drivers/tty/serial/pxa.c | 22 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git a/drivers/tty/serial
, PXA ports could be configured with different
name and device numbers.
Signed-off-by: Sergey Yanovich ynv...@gmail.com
---
drivers/tty/serial/Kconfig | 14 ++
drivers/tty/serial/pxa.c | 22 ++
2 files changed, 32 insertions(+), 4 deletions(-)
diff --git
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
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
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
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
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
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
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
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
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich
Signed-off-by: Sergey Yanovich <[EMAIL PROTECTED]>
---
drivers/mmc/tifm.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 5410e66..30cab30 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich
Signed-off-by: Sergey Yanovich <[EMAIL PROTECTED]>
---
drivers/mmc/tifm.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 5410e66..30cab30 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/
Signed-off-by: Sergey Yanovich [EMAIL PROTECTED]
---
drivers/mmc/tifm.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 5410e66..30cab30 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/tifm.c
@@ -28,15
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich
First, I tried to replace 'mdelay' with 'msleep' and put it after
'unlock'. It gives a certain oops.
With the delay of 50 msec driver remains stable. It has something
to do with hardware initialization, so this value should not be
affected by CPU speed. I hope so.
Signed-off-by: Sergey Yanovich
Signed-off-by: Sergey Yanovich [EMAIL PROTECTED]
---
drivers/mmc/tifm.c | 22 ++
1 files changed, 6 insertions(+), 16 deletions(-)
diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 5410e66..30cab30 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/tifm.c
@@ -28,15
by default for 686+ CPUs. And
this is far more overhead that a single check of card type on
insert.
To allow customization, boolean module options that disable certain
card type may suffice.
And again, you are doing a great work with the driver.
--
Sergey Yanovich
-
To unsubscribe from this list: send
by default for 686+ CPUs. And
this is far more overhead that a single check of card type on
insert.
To allow customization, boolean module options that disable certain
card type may suffice.
And again, you are doing a great work with the driver.
--
Sergey Yanovich
-
To unsubscribe from this list: send
nt that [tifm_7xx1], you would also need a
completely new modules for slots (sd, ms, etc).
--
Sergey Yanovich
-
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/
No, we ship a udev script.
OK, me bad for using the present tense. But you had a single module
in Oct 2006, didn't you? And maybe, you would like to post the script.
--
Sergey Yanovich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
script.
OK, me bad for using the present tense. But you had a single module
in Oct 2006, didn't you? And maybe, you would like to post the script.
--
Sergey Yanovich
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More
new modules for slots (sd, ms, etc).
--
Sergey Yanovich
-
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/
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
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
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
report any issues with this driver to
http://bugzilla.kernel.org/show_bug.cgi?id=8352 so that valuable info is
not lost.
Best regards,
Sergey Yanovich
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo inf
. Please also report any issues with this driver to
http://bugzilla.kernel.org/show_bug.cgi?id=8352 so that valuable info is
not lost.
Best regards,
Sergey Yanovich
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info
70 matches
Mail list logo
