Re: [PATCH v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 not worth cases. In total we have
> around 1.5 s to initialize the cards.

We have a separate workqueue per host, so all probes go in parallel.
They also go in parallel with probing for other devices. So the actual
delay is 700 ms minus maximum probing time for other devices. The time
is either zero or small (dozen us) on the hardware I have access to
(intel laptop, arm controller).

> Now, suppose you boot using an initrd image. Thus neither of the cards
> needs to be accessible immediately after the kernel has booted. It all
> depends what the init process decides to do. With this patch the init
> process will always be delayed to wait for each and every card to be
> initialized. I would prefer a solution where this can be configurable
> somehow, since certainly this is not the scenario you want for all
> cases.

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.

If root is on an mmc, kernel needs to wait for the mmc probe.

--
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 v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 is an addition of 310 ms which is 19% performance degradation.

Are you sure the delay is caused by mmc?

On my intel laptop (userspace is Debian/unstable):
[1.542339] EXT4-fs (sda2): mounted filesystem with ordered data mode. Opts: 
(null)
...
[2.735851] mmc0: new high speed SD card at address e624
[2.742289] mmcblk0: mmc0:e624 SU02G 1.84 GiB 
[2.752317]  mmcblk0: p1

> Please revert the patch.

Chris, could provide a pointer on how to improve the patch?

Maybe introduce mmc_is_hosting_root() and do something like:

-   mmc_flush_scheduled_work();
+   if (mmc_is_hosting_root())
+   mmc_flush_scheduled_work();

--
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 v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 after root is mounted.
> 
> This will not solve the problem when having one device intended for
> rootfs and some other for something else. Of course, as long as the
> devices uses the same mmc module. Once inserted, all devices will be
> probed.

I agree that is this special case there will be boot time regression.
However, this case is not guaranteed to boot without the patch or some
workaround.

> > If root is on an mmc, kernel needs to wait for the mmc probe.
> >
> 
> True, although your patch is preventing the parallelism and instead
> doing things in synchronized manner.

mount_root() assumes it has waited for "known devices to complete their
probing" [init/do_mounts.c:545]. The patch has brought mmc into
compliance with the assumption.

If several devices can be probed in parallel, the bus should do it, but
not the driver.

> I think we must discuss alternative solutions instead.
> 
> Like an "mmc detect flush" mechanism or a "new card device notification" 
> event.

There are 2 events to trigger root mount:
1. all known devices complete their probing
2. 1 is true and root_wait is specified and root device is found

So I see the only fast alternative to my patch: if root is on an mmc
card, set root_wait to 'true'.

--
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 v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 mmc_is_hosting_root() and do something like:
> > 
> > -   mmc_flush_scheduled_work();
> > +   if (mmc_is_hosting_root())
> > +   mmc_flush_scheduled_work();
> 
> No, I am booting from eMMC.  Perhaps a host capability:
> 
>   if (host->caps2 & MMC_CAP2_ROOTWAIT)
>   mmc_flush_scheduled_work();
> 

Neither my variant, nor yours will help to handle the increased boot
time.

The root cause is that probing several devices is done sequentially and
mmc was reporting end of its probing before it was actually happening.
My patch makes mmc report end of probing on-time. The correct way to fix
the additional delay, my patch introduces, is to rewrite the probing to
be parallel instead of sequential. I understand that it is much easier
just to revert the patch.

If the patch is reverted, something like this somewhere in
'init/do_mounts.c' could conditionally activate 'root_wait':

if (mmc_is_hosting_root())
root_wait = 1;

IMHO this is wrong and my patch is right, but better this than broken
mmc boot.

--
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 v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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. It may or may not boot each time
> > depending on the large number of factors.
> 
> Not true.  You know nothing of my boot time characteristics.

Well, I assumed you use linux kernel recent enough to include the patch
in question. This assumption may well be wrong.

Could you please elaborate how you avoid a situation which brought up
this patch ("all probes finish and mmc card is not ready")?

--
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/

[PATCH] allow alternative name for PXA serial console

[Sergey Yanovich]

ICP DAS LP-8x4x is an industrial data acquision device. It is based
on PXA270 CPU. The board containsi a lot of (up to 36) standard UARTi
8250i serial ports. System console on the board is provided with
an on-chip PXA serial port. Both modules use /dev/ttyS0 by default.

To solve the collision, 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/Kconfig b/drivers/tty/serial/Kconfig
index 59c23d0..09cf980 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -406,6 +406,20 @@ config SERIAL_PXA_CONSOLE
  your boot loader (lilo or loadlin) about how to pass options to the
  kernel at boot time.)
 
+config SERIAL_PXA_TTYSA_NAME
+   bool "as /dev/ttySA[0-3]"
+   depends on SERIAL_PXA
+   default N
+   help
+ If you have enabled the serial port on the Intel XScale PXA
+ CPU you can make it appear as /dev/ttySA[0-3] in the system.
+
+ If you say N here (default), the ports will use UART /dev/ttyS[0-3]
+ names and corresponding major and minor devices numbers.
+
+ If you say Y here, the ports will have SA-1100 style names and
+ numbers. It is reqired at least for one PXA based device.
+
 config SERIAL_SA1100
bool "SA1100 serial port support"
depends on ARCH_SA1100
diff --git a/drivers/tty/serial/pxa.c b/drivers/tty/serial/pxa.c
index 2764828..a7e5e40 100644
--- a/drivers/tty/serial/pxa.c
+++ b/drivers/tty/serial/pxa.c
@@ -619,6 +619,20 @@ serial_pxa_type(struct uart_port *port)
 static struct uart_pxa_port *serial_pxa_ports[4];
 static struct uart_driver serial_pxa_reg;
 
+#ifndef CONFIG_SERIAL_PXA_TTYSA_NAME
+
+#define PXA_TTY_NAME   "ttyS"
+#define PXA_TTY_MAJOR  TTY_MAJOR
+#define PXA_TTY_MINOR  64
+
+#else
+
+#define PXA_TTY_NAME   "ttySA"
+#define PXA_TTY_MAJOR  204
+#define PXA_TTY_MINOR  5
+
+#endif
+
 #ifdef CONFIG_SERIAL_PXA_CONSOLE
 
 #define BOTH_EMPTY (UART_LSR_TEMT | UART_LSR_THRE)
@@ -778,7 +792,7 @@ serial_pxa_console_setup(struct console *co, char *options)
 }
 
 static struct console serial_pxa_console = {
-   .name   = "ttyS",
+   .name   = PXA_TTY_NAME,
.write  = serial_pxa_console_write,
.device = uart_console_device,
.setup  = serial_pxa_console_setup,
@@ -819,9 +833,9 @@ struct uart_ops serial_pxa_pops = {
 static struct uart_driver serial_pxa_reg = {
.owner  = THIS_MODULE,
.driver_name= "PXA serial",
-   .dev_name   = "ttyS",
-   .major  = TTY_MAJOR,
-   .minor  = 64,
+   .dev_name   = PXA_TTY_NAME
+   .major  = PXA_TTY_MAJOR,
+   .minor  = PXA_TTY_MINOR,
.nr = 4,
.cons   = PXA_CONSOLE,
 };
-- 
1.7.10.4

--
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/

gcc/binutils bug suspected -- recommended actions?

[Sergey Yanovich]

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 __arm_ioremap_pfn_caller+0x244/0x280
pc : []lr : []psr: 4013
sp : c782ddf0  ip :   fp : c782de14
r10: c04b4010  r9 :   r8 : 0065
r7 : c04d4c28  r6 : c04d4fd0  r5 : c04d4f88  r4 : c79fec20
r3 :   r2 : 0001  r1 : fffe8000  r0 : ce00
Flags: nZcv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 397f  Table: a0004000  DAC: 0017
Process swapper (pid: 1, stack limit = 0xc782c1c0)
Stack: (0xc782ddf0 to 0xc782e000)
dde0: c00d92a8 c00d906c c04d4c38 c04d4c6c
de00: c04e24a4 c01fdd0c c782de24 c782de18 c01fed10 c0226ab0 c782de44 c782de28
de20: c01fdbc0 c01fed00  c04d4c38 c04d4c6c c04e24a4 c782de64 c782de48
de40: c01fdd7c c01fdb24   c782de68 c04e24a4 c782de8c c782de68
de60: c01fc218 c01fdd18 c78223cc c784fd50 c04e24a4 c7b05cc0 c04e13e8 
de80: c782de9c c782de90 c01fd72c c01fc1c8 c782decc c782dea0 c01fd2f0 c01fd718
dea0: c0454004 c04c4bc4 c782decc c04e24a4 c04bdfa0 c04c4bc4 c04eb700 0065
dec0: c782def4 c782ded0 c01fe0b4 c01fd228 0006 c04bdfa0 c04c4bc4 c04eb700
dee0: 0065 c04b4010 c782df04 c782def8 c01fef58 c01fe01c c782df14 c782df08
df00: c04b4024 c01fef18 c782df54 c782df18 c00085f4 c04b401c 0006 0006
df20: 0065 c04a185c c782df54 0006 c04bdfa0 c04c4bc4 c04eb700 0065
df40:  c04bdfac c782df94 c782df58 c04a38e4 c0008564 0006 0006
df60: c04a31a8 2d861c1d e3030f2f 2c3f5f87  c0344258  
df80:   c782dfac c782df98 c0344268 c04a37fc  
dfa0:  c782dfb0 c00091b0 c0344264    
dfc0:        
dfe0:     0013  cf930707 172e4f0d
Backtrace:
[] (pxa2xx_flash_probe+0x0/0x1a8) from [] 
(platform_drv_probe+0x1c/0x20)
 r7:c01fdd0c r6:c04e24a4 r5:c04d4c6c r4:c04d4c38
[] (platform_drv_probe+0x0/0x20) from [] 
(driver_probe_device+0xa8/0x1f4)
[] (driver_probe_device+0x0/0x1f4) from [] 
(__driver_attach+0x70/0x94)
 r6:c04e24a4 r5:c04d4c6c r4:c04d4c38 r3:
[] (__driver_attach+0x0/0x94) from [] 
(bus_for_each_dev+0x5c/0x98)
 r6:c04e24a4 r5:c782de68 r4: r3:
[] (bus_for_each_dev+0x0/0x98) from [] 
(driver_attach+0x20/0x28)
 r7: r6:c04e13e8 r5:c7b05cc0 r4:c04e24a4
[] (driver_attach+0x0/0x28) from [] 
(bus_add_driver+0xd4/0x22c)
[] (bus_add_driver+0x0/0x22c) from [] 
(driver_register+0xa4/0x134)
 r8:0065 r7:c04eb700 r6:c04c4bc4 r5:c04bdfa0 r4:c04e24a4
[] (driver_register+0x0/0x134) from [] 
(platform_driver_register+0x4c/0x60)
[] (platform_driver_register+0x0/0x60) from [] 
(pxa2xx_flash_driver_init+0x14/0x1c)
[] (pxa2xx_flash_driver_init+0x0/0x1c) from [] 
(do_one_initcall+0x9c/0x174)
[] (do_one_initcall+0x0/0x174) from [] 
(kernel_init_freeable+0xf4/0x1b4)
[] (kernel_init_freeable+0x0/0x1b4) from [] 
(kernel_init+0x10/0xec)
[] (kernel_init+0x0/0xec) from [] (ret_from_fork+0x14/0x24)
 r4: r3:
Code: e3eb ea0e e3e4 ea0c (e7f001f2)
---[ end trace d485c4bc3d1e9fb9 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x000b

The complier is debian gcc-4.7-arm-linux-gnueabi (4.7.2-5). objdump of the 
failing
function contains a strange instruction at the failure address:


c0226b5c:   eb0479d6bl  c03452bc 
c0226b60:   e59f30d8ldr r3, [pc, #216]  ; c0226c40 

c0226b64:   e5843020str r3, [r4, #32]
c0226b68:   e594301cldr r3, [r4, #28]
c0226b6c:   e3530004cmp r3, #4
c0226b70:   8a1fbhi c0226bf4 
c0226b74:   e3a02001mov r2, #1
c0226b78:   e1a02312lsl r2, r2, r3
c0226b7c:   e3120016tst r2, #22
c0226b80:   1a1cbne c0226bf8 
c0226b84:   ea1ab   c0226bf4 
c0226b88:   e5940010ldr r0, [r4, #16]
c0226b8c:   ebf7a396bl  c000f9ec <__arm_iounmap>
c0226b90:   e5940014ldr r0, [r4, #20]
c0226b94:   e350cmp r0, #0
c0226b98:   0a13beq c0226bec 
c0226b9c:   ebf7a392bl  c000f9ec <__arm_iounmap>
c0226ba0:   ea11b   c0226bec 
c0226ba4:   e3a06000mov r6, #0
c0226ba8:   e58060e0str r6, [r0, #224]  ; 0xe0
c0226bac:   e5953020ldr r3, [r5, #32]
c0226bb0:   e59f108cldr r1, [pc, #140]  ; c0226c44 

c0226bb4:   e1a02006mov r2, r6
c0226bb8:   e58d3000str r3, [sp]
c0226bbc:   e595301cldr r3, [r5, #28]
c0226bc0:   

[PATCH] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.
---8<---
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not support reading read-only switch. assuming write-enable.
1f00 256 mtdblock0  (driver?)
1f01 256 mtdblock1  (driver?)
1f022560 mtdblock2 mmc0: new SDHC card at address b368
 (driver?)
1f03   29696 mtdblock3  (driver?)
1f04   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 
---
 drivers/base/dd.c   |1 -
 drivers/mmc/core/core.c |4 +++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/drivers/base/dd.c b/drivers/base/dd.c
index 218f1e6..61d3e1b 100644
--- a/drivers/base/dd.c
+++ b/drivers/base/dd.c
@@ -345,7 +345,6 @@ int driver_probe_done(void)
 void wait_for_device_probe(void)
 {
/* wait for the known devices to complete their probing */
-
wait_event(probe_waitqueue, atomic_read(&probe_count) == 0);
async_synchronize_full();
 }
diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aaed768..9790323 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -91,10 +91,11 @@ static int mmc_schedule_delayed_work(struct delayed_work 
*work,
 /*
  * Internal function. Flush all scheduled work from the MMC work queue.
  */
-static void mmc_flush_scheduled_work(void)
+void mmc_flush_scheduled_work(void)
 {
flush_workqueue(workqueue);
 }
+EXPORT_SYMBOL(mmc_flush_scheduled_work);
 
 #ifdef CONFIG_FAIL_MMC_REQUEST
 
@@ -2225,6 +2226,7 @@ void mmc_start_host(struct mmc_host *host)
host->rescan_disable = 0;
mmc_power_up(host);
mmc_detect_change(host, 0);
+   mmc_flush_scheduled_work();
 }
 
 void mmc_stop_host(struct mmc_host *host)
-- 
1.7.10.4

--
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/

[PATCH v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

MMC hosts are added asynchronously. We need to wait until detect returns to
avoid failed root filesystem mounts.
---8<---
VFS: Cannot open root device "mmcblk0p1" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
mmc0: host does not support reading read-only switch. assuming write-enable.
1f00 256 mtdblock0  (driver?)
1f01 256 mtdblock1  (driver?)
1f022560 mtdblock2 mmc0: new SDHC card at address b368
 (driver?)
1f03   29696 mtdblock3  (driver?)
1f04   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 for v2:
- removed exporting as symbol is in the same file

 drivers/mmc/core/core.c |1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/mmc/core/core.c b/drivers/mmc/core/core.c
index aaed768..7196888 100644
--- a/drivers/mmc/core/core.c
+++ b/drivers/mmc/core/core.c
@@ -2225,6 +2225,7 @@ void mmc_start_host(struct mmc_host *host)
host->rescan_disable = 0;
mmc_power_up(host);
mmc_detect_change(host, 0);
+   mmc_flush_scheduled_work();
 }
 
 void mmc_stop_host(struct mmc_host *host)
-- 
1.7.10.4

--
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] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 don't.


Got the point.


mmc_detect_change(host, 0);
+   mmc_flush_scheduled_work();


If this is the only fix, then you don't need to change it from being
static or need to export it.

Please be more careful when making kernel patches.


I will. I apologize for spamming.
--
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 v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 delay in the range of hundreds 
milliseconds and seconds respectively. They delay is not required. If a cards 
is present, mmc_rescan will return synchronously with card initialized.

prepare_namespace() uses wait_for_device_probe(). The latter assumes that all "known 
devices" have initialized by the time it returns. MMC is not currently delivering on 
the assumptions. It will with the patch applied.
--
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] rtc-ds1302: handle write protection

[Sergey Yanovich]

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);
> >  
> > +   ds1302_writebyte(RTC_ADDR_CTRL, RTC_CMD_WRITE_DISABLE);
> > rtc_device_unregister(rtc);
> > platform_set_drvdata(pdev, NULL);
> 
> ds1302_rtc_remove() no longer exists in my tree - it got whittled away
> to nothing by
> http://ozlabs.org/~akpm/mmots/broken-out/rtc-rtc-ds1302-remove-unnecessary-platform_set_drvdata.patch
> and
> http://ozlabs.org/~akpm/mmots/broken-out/drivers-rtc-rtc-ds1302c-remove-empty-function.patch
> 
> Perhaps it should be re-added for this?

There are 2 options. I would be happy with either.

1. I've chosen 'probe/remove' to enable/disable write access.

2. Another option is to wrap enable/disable around
ds1302_rtc_set_time().

IIUC, the former saves a few bytes of memory. However, now, when
ds1302_rtc_remove() is gone, the latter looks better. So I could rewrite
the patch either way.

--
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/

[PATCH] rtc-ds1302: handle write protection

[Sergey Yanovich]

>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:
8<
(arm)root@pac14:~# date
Tue May 21 03:08:27 MSK 2013
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:13:58 2013  -0.067322 seconds
(arm)root@pac14:~# /etc/init.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<

The patch enables write access to rtc before the driver tries to write time
and re-disables when time data is written.

Signed-off-by: Sergey Yanovich 

 # Changes to be committed:
---
changes for v2:
 - do enable/disable around set_time() instead of in probe()/remove()

 drivers/rtc/rtc-ds1302.c |7 +++
 1 file changed, 7 insertions(+)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 7533b72..07e8d79 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -23,8 +23,12 @@
 #defineRTC_CMD_READ0x81/* Read command */
 #defineRTC_CMD_WRITE   0x80/* Write command */
 
+#defineRTC_CMD_WRITE_ENABLE0x00/* Write enable */
+#defineRTC_CMD_WRITE_DISABLE   0x80/* Write disable */
+
 #define RTC_ADDR_RAM0  0x20/* Address of RAM0 */
 #define RTC_ADDR_TCR   0x08/* Address of trickle charge register */
+#defineRTC_ADDR_CTRL   0x07/* Address of control register 
*/
 #defineRTC_ADDR_YEAR   0x06/* Address of year register */
 #defineRTC_ADDR_DAY0x05/* Address of day of week 
register */
 #defineRTC_ADDR_MON0x04/* Address of month register */
@@ -161,6 +165,7 @@ static int ds1302_rtc_read_time(struct device *dev, struct 
rtc_time *tm)
 
 static int ds1302_rtc_set_time(struct device *dev, struct rtc_time *tm)
 {
+   ds1302_writebyte(RTC_ADDR_CTRL, RTC_CMD_WRITE_ENABLE);
/* Stop RTC */
ds1302_writebyte(RTC_ADDR_SEC, ds1302_readbyte(RTC_ADDR_SEC) | 0x80);
 
@@ -175,6 +180,8 @@ static int ds1302_rtc_set_time(struct device *dev, struct 
rtc_time *tm)
/* Start RTC */
ds1302_writebyte(RTC_ADDR_SEC, ds1302_readbyte(RTC_ADDR_SEC) & ~0x80);
 
+   ds1302_writebyte(RTC_ADDR_CTRL, RTC_CMD_WRITE_DISABLE);
+
return 0;
 }
 
-- 
1.7.10.4

--
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/

[PATCH] 1-wire: in-kernel notification on device events

[Sergey Yanovich]

Before this patch 1-wire subsystem didn't provide access to its
add/remove events to other parts of the kernel. Now it is possible
to register a standard notifier_block observer, which will be informed
of subsequent device insertions and removals.

The framework is copied from USB subsystem.

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 +
 drivers/w1/w1_netlink.h |   11 +--
 include/linux/w1.h  |  176 +++
 8 files changed, 279 insertions(+), 158 deletions(-)
 create mode 100644 drivers/w1/notify.c
 create mode 100644 include/linux/w1.h

diff --git a/drivers/w1/Kconfig b/drivers/w1/Kconfig
index 6743bde..d33d074 100644
--- a/drivers/w1/Kconfig
+++ b/drivers/w1/Kconfig
@@ -25,6 +25,13 @@ config W1_CON
  2. Userspace commands. Includes read/write and search/alarm search 
commands.
  3. Replies to userspace commands.
 
+config W1_NOTIFY
+   bool "Dallas's 1-wire device notifications"
+   default n
+   ---help---
+ This allows other parts of kernel to be notified of 1-wire hotplug
+ events.
+
 source drivers/w1/masters/Kconfig
 source drivers/w1/slaves/Kconfig
 
diff --git a/drivers/w1/Makefile b/drivers/w1/Makefile
index 6bb0b54..233ec84 100644
--- a/drivers/w1/Makefile
+++ b/drivers/w1/Makefile
@@ -3,7 +3,8 @@
 #
 
 obj-$(CONFIG_W1)   += wire.o
-wire-objs  := w1.o w1_int.o w1_family.o w1_netlink.o w1_io.o
+wire-objs  := w1.o w1_int.o w1_family.o w1_netlink.o w1_io.o \
+   notify.o
 
 obj-y  += masters/ slaves/
 
diff --git a/drivers/w1/notify.c b/drivers/w1/notify.c
new file mode 100644
index 000..2b4a123
--- /dev/null
+++ b/drivers/w1/notify.c
@@ -0,0 +1,76 @@
+/*
+ * linux/drivers/w1/notify.c
+ *
+ * Notification logic for 1-wire subsystem
+ *
+ * (C) Copyright 2013 Sergey Yanovich
+ *
+ * This is mostly a copy with s/usb/w1/gc from
+ * linux/drivers/usb/notify.c
+ *
+ * All the USB notify logic
+ *
+ * (C) Copyright 2005 Greg Kroah-Hartman 
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ */
+
+#ifdef CONFIG_W1_NOTIFY
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include "w1.h"
+
+static BLOCKING_NOTIFIER_HEAD(w1_notifier_list);
+
+/**
+ * w1_register_notify - register a notifier callback whenever a w1 change 
happens
+ * @nb: pointer to the notifier block for the callback events.
+ *
+ * These changes are either w1 devices or busses being added or removed.
+ */
+void w1_register_notify(struct notifier_block *nb)
+{
+   blocking_notifier_chain_register(&w1_notifier_list, nb);
+}
+EXPORT_SYMBOL_GPL(w1_register_notify);
+
+/**
+ * w1_unregister_notify - unregister a notifier callback
+ * @nb: pointer to the notifier block for the callback events.
+ *
+ * w1_register_notify() must have been previously called for this function
+ * to work properly.
+ */
+void w1_unregister_notify(struct notifier_block *nb)
+{
+   blocking_notifier_chain_unregister(&w1_notifier_list, nb);
+}
+EXPORT_SYMBOL_GPL(w1_unregister_notify);
+
+void w1_notify_add_slave(struct w1_slave *dev)
+{
+   blocking_notifier_call_chain(&w1_notifier_list, W1_SLAVE_ADD, dev);
+}
+
+void w1_notify_remove_slave(struct w1_slave *dev)
+{
+   blocking_notifier_call_chain(&w1_notifier_list, W1_SLAVE_REMOVE, dev);
+}
+
+void w1_notify_add_master(struct w1_master *bus)
+{
+   blocking_notifier_call_chain(&w1_notifier_list, W1_MASTER_ADD, bus);
+}
+
+void w1_notify_remove_master(struct w1_master *bus)
+{
+   blocking_notifier_call_chain(&w1_notifier_list, W1_MASTER_REMOVE, bus);
+}
+#endif
diff --git a/drivers/w1/w1.c b/drivers/w1/w1.c
index 7994d933..f546005 100644
--- a/drivers/w1/w1.c
+++ b/drivers/w1/w1.c
@@ -709,6 +709,7 @@ static int w1_attach_slave_device(struct w1_master *dev, 
struct w1_reg_num *rn)
memcpy(msg.id.id, rn, sizeof(msg.id));
msg.type = W1_SLAVE_ADD;
w1_netlink_send(dev, &msg);
+   w1_notify_add_slave(sl);
 
return 0;
 }
@@ -728,6 +729,7 @@ void w1_slave_detach(struct w1_slave *sl)
memcpy(msg.id.id, &sl->reg_num, sizeof(msg.id));
msg.type = W1_SLAVE_REMOVE;
w1_netlink_send(sl->master, &msg);
+   w1_notify_remove_slave(sl);
 
device_remove_file(&sl->dev, &w1_slave_attr_id);
device_remove_file(&sl->dev, &w1_slave_attr_name);
diff --git a/drivers/w1/w1.h b/drivers/w1/w1.h
index 45908e5..a600e35 100644
--- a/drive

Re: [PATCH v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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 the host
is a device). In this case, the probing could be done asynchronously
without breaking the assumption in prepare_namespace().

Chris, could you comment?

--
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 v2] wait while adding MMC host to ensure root mounts

[Sergey Yanovich]

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
> > without breaking the assumption in prepare_namespace().
> 
> Actually the card is already a separate device, which I connected to
> the mmc bus.

Great. I failed to see that.

> It is an interesting idea, but the problem is that the card device is
> only created and added on the fly when a card has been properly
> detected.

If we include 'detecting' in 'probing' and then do 'probing'
asynchronously, we will neither have race condition, nor boot time
regression.

--
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/

[PATCH] rtc-ds1302: handle write protection

[Sergey Yanovich]

This chip has a control register and can prevent altering saved clock.
Without this patch we could have:
8<
(arm)root@pac14:~# date
Tue May 21 03:08:27 MSK 2013
(arm)root@pac14:~# /etc/init.d/hwclock.sh show
Tue May 21 11:13:58 2013  -0.067322 seconds
(arm)root@pac14:~# /etc/init.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 changed, 6 insertions(+)

diff --git a/drivers/rtc/rtc-ds1302.c b/drivers/rtc/rtc-ds1302.c
index 73eafb9..626aec2 100644
--- a/drivers/rtc/rtc-ds1302.c
+++ b/drivers/rtc/rtc-ds1302.c
@@ -23,8 +23,12 @@
 #defineRTC_CMD_READ0x81/* Read command */
 #defineRTC_CMD_WRITE   0x80/* Write command */
 
+#defineRTC_CMD_WRITE_ENABLE0x00/* Write enable */
+#defineRTC_CMD_WRITE_DISABLE   0x80/* Write disable */
+
 #define RTC_ADDR_RAM0  0x20/* Address of RAM0 */
 #define RTC_ADDR_TCR   0x08/* Address of trickle charge register */
+#defineRTC_ADDR_CTRL   0x07/* Address of control register 
*/
 #defineRTC_ADDR_YEAR   0x06/* Address of year register */
 #defineRTC_ADDR_DAY0x05/* Address of day of week 
register */
 #defineRTC_ADDR_MON0x04/* Address of month register */
@@ -313,6 +317,7 @@ static int __init ds1302_rtc_probe(struct platform_device 
*pdev)
return PTR_ERR(rtc);
 
platform_set_drvdata(pdev, rtc);
+   ds1302_writebyte(RTC_ADDR_CTRL, RTC_CMD_WRITE_ENABLE);
 
return 0;
 }
@@ -321,6 +326,7 @@ static int ds1302_rtc_remove(struct platform_device *pdev)
 {
struct rtc_device *rtc = platform_get_drvdata(pdev);
 
+   ds1302_writebyte(RTC_ADDR_CTRL, RTC_CMD_WRITE_DISABLE);
rtc_device_unregister(rtc);
platform_set_drvdata(pdev, NULL);
 
-- 
1.7.10.4

--
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/

[mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

Hi,

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 failure used to be trigerred by a fast card 
insert/removal sequence. Finally, tifm_sd module needs to be manually 
inserted.


I have found it easier to rewrite the driver, than to fix. This driver 
is kind of mutant. The bones are taken from sdhci and omap, the meat - 
from tifm_*. It contains all features (and bugs except named above) of 
tifm_* as it was in kernel 2.6.21-rc7.


I have been testing this version since linux-2.6.18 (daily reading 
photos from cards, daily suspending/resuming) without a single glitch.


This patch only provides sources.
http://bugzilla.kernel.org/attachment.cgi?id=11238&action=view

Kernel configuration in this message.
http://bugzilla.kernel.org/attachment.cgi?id=11239&action=view

Alex Dubov has done exceptionally great lots of work to teach linux 
speak to TIFM. This is just a reorganization of his project.


The driver seems to be practically stable, but it definitely must be 
tested by more people. 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 at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 message was blocked
by the list as it contained html.

For inlinning, this is my first kernel patch. I have just followed
http://www.tux.org/lkml/#s2-2.

You should include the Makefile and Kconfig changes in the same patch/mail,
no point splitting these out.
  
Once again it was an advise from http://www.tux.org/lkml/#s1-10. 


Don't define your own DBG macro, instead use the predefined dev_dbg()
that has a similar definition.
  
Somewhere in 0.5-0.6 version this driver has issues with timeouts , 
which were
revealing in a non-debug kernel builds only . So this was a nessecity. I 
will purge

them now.

Your mmc_tifm_irq_chip() function does a _very_ long delay of 100
miliseconds. This is normally not acceptable, since it is a noticeable
time in which the system is completely unresponsive. Maybe you can convert
the tasklet to a workqueue, which lets you call msleep instead of mdelay.
  
This is done intentionally to prevent a race condition when a card is 
removed
and immediately reinserted. There may be a more complicated way to solve 
this
issue, but didn't think about them. This only happens when an MMC/SD 
card is
inserted/removed. And it takes at least as long to process the event in 
other

parts of subsystem.

Your use of pci_map_sg() looks wrong, you simply can't assume that the
return value is '1' in general. I've stumbled over that same problem
in the sdhci driver, so it may be inherent to the mmc layer and not
be driver specific.
  

This is taken as is from [tifm_sd]. I suppose this relates to a hardware
limitation:

+   mmc->max_hw_segs = 1;
+   mmc->max_phys_segs = 1;


Best regards,
Sergey
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 tested
it using SD and MMC .. I've not been able to fault it now. In fact, 
checking my mail archives, my
last reported bug was on the 17th of Feb and it has been rock solid 
since. I just don't think about

it anymore, it simply works...



Well, I am tracking Alex's svn. It is for off-the-tree builds. I 
reorganized Alex's code in Oct 2006 and added
a patch to my debian/patches. Until debian shipped linux-2.6.20, there 
were no [tifm_*] in their tree, so no conflicts. The 2.6.20 came with 
tifm_sd-v0.6 which is not so stable. I dug lkml and bugzilla.kernel.org 
for fresh patches, but found 
http://bugzilla.kernel.org/show_bug.cgi?id=8052. Which made me think, 
svn is still unstable. I merged in-kernel updates to my old (v2.6.18-*) 
version. It compiles and runs OK, so I posted it. No offense to anyone.


Best regards,
Sergey
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 if you to provide a sample script. Unfortunately,
hotplug scripts are distribution specific. And internal knowledge of
your modules is required to write one.

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.

And maybe, you would care to create a branch in you repository for
in-the-tree compiles.


As I already said before, many of the complications exist because this is  an 
universal adapter,
and memorystick support is quite near in the queue.


The scope of your project is exceptionally wide. You plan to develop a whole
new layer for memorystick as a part.

At the same time, the [tifm_sd] code is device specific, and [tifm_7xx1]
code is also device specific. And both modules depend on the same device
(of family of devices). That makes me think that a bus/controller/slot
construction is not going to make thing any easier, but adds complexity.

In case of MMC/SD all abstraction has already been separated by the mmc
layer, in case of MS it is up to you, how to implement.
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

> 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 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 majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 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 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/

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 propose to do with
adapters that have SD support disabled? There are quite a few of those in the 
wild, as of right
now (SD support is provided by bundled SDHCI on such systems, if at all). 
Similar argument goes
for other media types as well - many controllers have xD support disabled too 
(I think you have
one of those - Sony really values its customers). After all, it is not healthy 
to have dead code
in the kernel.


A typical kernel config is an allmconfig, which has tones of dead
code: just see a 'General setup' part of your distro '.config'.
There are item like 'SMP' selected 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 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] [mmc] Removes custom debug macro

[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 +28,6 @@
 #define DRIVER_NAME "tifm"
 #define DRIVER_VERSION "0.7"
 
-/*#define CONFIG_MMC_DEBUG*/
-#ifdef CONFIG_MMC_DEBUG
-#define DBG(f,arg...) \
-   printk(KERN_DEBUG DRIVER_NAME ": " f,##arg)
-#else /* CONFIG_MMC_DEBUG */
-#define DBG(f,arg...) \
-   do { } while (0)
-#endif /* CONFIG_MMC_DEBUG */
-
 static int no_dma = 0;
 
 struct tifm_chip;
@@ -594,7 +585,6 @@ mmc_tifm_irq(int irq, void *dev_id)
if(card_status && chip->socket[cnt])
mmc_tifm_irq_card(chip->socket[cnt],card_status);
}
-   /*DBG("got irq status 0x%08x\n", irq_status);*/
spin_unlock(&chip->lock);
return IRQ_HANDLED;
 }
@@ -611,7 +601,7 @@ mmc_tifm_request(struct mmc_host *mmc, struct mmc_request 
*mrq)
struct mmc_data *data = mrq->cmd->data;
 
spin_lock_irqsave(&socket->lock, flags);
-   DBG("executing opcode %u\n",mrq->cmd->opcode);
+   dev_dbg(socket->chip->pdev,"executing opcode %u\n",mrq->cmd->opcode);
if(!(socket->flags & POWER_ON)){
spin_unlock_irqrestore(&socket->lock, flags);
goto err_out;
@@ -665,7 +655,7 @@ mmc_tifm_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
int cnt;
 
spin_lock_irqsave(&socket->lock, flags);
-   DBG("setting io for socket %u\n",socket->index);
+   dev_dbg(socket->chip->pdev,"setting io for socket %u\n",socket->index);
 
if(!(socket->flags & MEDIA_MMC)){
writel(0,socket->addr + SOCK_MMCSD_INT_ENABLE);
@@ -808,7 +798,7 @@ mmc_tifm_suspend(struct pci_dev *pdev, pm_message_t state)
spin_unlock_irqrestore(chip->socket[cnt]->lock,flags);
mmc=container_of((void*)chip->socket[cnt],
struct mmc_host,private);
-   DBG(" ... socket %u\n",cnt);
+   dev_dbg(chip->pdev," ... socket %u\n",cnt);
mmc_suspend_host(mmc,state);
spin_lock_irqsave(chip->socket[cnt]->lock,flags);
chip->socket[cnt]->flags = 0;
@@ -889,14 +879,14 @@ mmc_tifm_probe_socket(struct tifm_chip *chip, int num)
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
mmc->max_seg_size = mmc->max_req_size;
 
-   DBG("initing tasklets for socket %u\n",num);
+   dev_dbg(chip->pdev,"initing tasklets for socket %u\n",num);
tasklet_init(&socket->irq_chip,mmc_tifm_irq_chip,(unsigned long)socket);
tasklet_init(&socket->cmd_end,mmc_tifm_cmd_end,(unsigned long)socket);
setup_timer(&socket->timer,mmc_tifm_timer,(unsigned long)socket);
chip->socket[num] = socket;
tifm_socket_event(chip,num,1);
 
-   DBG("adding mmc host for socket %u\n",num);
+   dev_dbg(chip->pdev,"adding mmc host for socket %u\n",num);
mmc_add_host(mmc);

return rc;
@@ -983,7 +973,7 @@ mmc_tifm_probe(struct pci_dev *pdev, const struct 
pci_device_id *dev_id)
else
break;
}
-   DBG("created %u socket(s)\n",sockets-cnt-1);
+   dev_dbg(chip->pdev,"created %u socket(s)\n",sockets-cnt-1);
if(rc)
goto err_out_unmap;
return 0;
-- 
1.5.1.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/

[PATCH] [mmc] [tifm] Reduces delay in card insert/removal

[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 <[EMAIL PROTECTED]>
---
 drivers/mmc/tifm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 30cab30..310f07c 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/tifm.c
@@ -361,7 +361,7 @@ mmc_tifm_irq_chip(unsigned long param)
socket->state = READY;
tasklet_schedule(&socket->cmd_end);
}
-   mdelay(100);
+   mdelay(50);
spin_unlock_irqrestore(&socket->lock, flags);
mmc_detect_change(mmc, 0);
 }
-- 
1.5.1.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/

[PATCH] [mmc] [tifm] Reduces delay in card insert/removal

[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 <[EMAIL PROTECTED]>
---
 drivers/mmc/tifm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 30cab30..310f07c 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/tifm.c
@@ -361,7 +361,7 @@ mmc_tifm_irq_chip(unsigned long param)
socket->state = READY;
tasklet_schedule(&socket->cmd_end);
}
-   mdelay(100);
+   mdelay(50);
spin_unlock_irqrestore(&socket->lock, flags);
mmc_detect_change(mmc, 0);
 }
-- 
1.5.1.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/

[PATCH] [mmc] [tifm] Reduces delay in card insert/removal

[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 <[EMAIL PROTECTED]>
---
 drivers/mmc/tifm.c |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/drivers/mmc/tifm.c b/drivers/mmc/tifm.c
index 30cab30..310f07c 100644
--- a/drivers/mmc/tifm.c
+++ b/drivers/mmc/tifm.c
@@ -361,7 +361,7 @@ mmc_tifm_irq_chip(unsigned long param)
socket->state = READY;
tasklet_schedule(&socket->cmd_end);
}
-   mdelay(100);
+   mdelay(50);
spin_unlock_irqrestore(&socket->lock, flags);
mmc_detect_change(mmc, 0);
 }
-- 
1.5.1.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/

[PATCH] [mmc] Removes custom debug macro

[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 +28,6 @@
 #define DRIVER_NAME "tifm"
 #define DRIVER_VERSION "0.7"
 
-/*#define CONFIG_MMC_DEBUG*/
-#ifdef CONFIG_MMC_DEBUG
-#define DBG(f,arg...) \
-   printk(KERN_DEBUG DRIVER_NAME ": " f,##arg)
-#else /* CONFIG_MMC_DEBUG */
-#define DBG(f,arg...) \
-   do { } while (0)
-#endif /* CONFIG_MMC_DEBUG */
-
 static int no_dma = 0;
 
 struct tifm_chip;
@@ -594,7 +585,6 @@ mmc_tifm_irq(int irq, void *dev_id)
if(card_status && chip->socket[cnt])
mmc_tifm_irq_card(chip->socket[cnt],card_status);
}
-   /*DBG("got irq status 0x%08x\n", irq_status);*/
spin_unlock(&chip->lock);
return IRQ_HANDLED;
 }
@@ -611,7 +601,7 @@ mmc_tifm_request(struct mmc_host *mmc, struct mmc_request 
*mrq)
struct mmc_data *data = mrq->cmd->data;
 
spin_lock_irqsave(&socket->lock, flags);
-   DBG("executing opcode %u\n",mrq->cmd->opcode);
+   dev_dbg(socket->chip->pdev,"executing opcode %u\n",mrq->cmd->opcode);
if(!(socket->flags & POWER_ON)){
spin_unlock_irqrestore(&socket->lock, flags);
goto err_out;
@@ -665,7 +655,7 @@ mmc_tifm_set_ios(struct mmc_host *mmc, struct mmc_ios *ios)
int cnt;
 
spin_lock_irqsave(&socket->lock, flags);
-   DBG("setting io for socket %u\n",socket->index);
+   dev_dbg(socket->chip->pdev,"setting io for socket %u\n",socket->index);
 
if(!(socket->flags & MEDIA_MMC)){
writel(0,socket->addr + SOCK_MMCSD_INT_ENABLE);
@@ -808,7 +798,7 @@ mmc_tifm_suspend(struct pci_dev *pdev, pm_message_t state)
spin_unlock_irqrestore(chip->socket[cnt]->lock,flags);
mmc=container_of((void*)chip->socket[cnt],
struct mmc_host,private);
-   DBG(" ... socket %u\n",cnt);
+   dev_dbg(chip->pdev," ... socket %u\n",cnt);
mmc_suspend_host(mmc,state);
spin_lock_irqsave(chip->socket[cnt]->lock,flags);
chip->socket[cnt]->flags = 0;
@@ -889,14 +879,14 @@ mmc_tifm_probe_socket(struct tifm_chip *chip, int num)
mmc->max_req_size = mmc->max_blk_size * mmc->max_blk_count;
mmc->max_seg_size = mmc->max_req_size;
 
-   DBG("initing tasklets for socket %u\n",num);
+   dev_dbg(chip->pdev,"initing tasklets for socket %u\n",num);
tasklet_init(&socket->irq_chip,mmc_tifm_irq_chip,(unsigned long)socket);
tasklet_init(&socket->cmd_end,mmc_tifm_cmd_end,(unsigned long)socket);
setup_timer(&socket->timer,mmc_tifm_timer,(unsigned long)socket);
chip->socket[num] = socket;
tifm_socket_event(chip,num,1);
 
-   DBG("adding mmc host for socket %u\n",num);
+   dev_dbg(chip->pdev,"adding mmc host for socket %u\n",num);
mmc_add_host(mmc);

return rc;
@@ -983,7 +973,7 @@ mmc_tifm_probe(struct pci_dev *pdev, const struct 
pci_device_id *dev_id)
else
break;
}
-   DBG("created %u socket(s)\n",sockets-cnt-1);
+   dev_dbg(chip->pdev,"created %u socket(s)\n",sockets-cnt-1);
if(rc)
goto err_out_unmap;
return 0;
-- 
1.5.1.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/

Re: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 looks more like reorganising the code
that's already there.


It is a sad truth. Instead of raising real issues that may remain in the 
driver, I was presented
with "non-proof" that bus-adapter-device architecture I'm using is somehow bad 
and the driver
should be turned into a monolithic blob, using config variables to disable 
unneeded functionality.
Considering, that udev handles automatic loading of the drivers just fine (so 
it's not an end user
issue at any rate), I don't see any justification for the change.


I may be doing something the wrong way. I absolutely don't intend to
start flames in this list.

Alex, your driver is great. You have done enormous amount of work,
reverse engineering proprietary drivers. Since the territory you work on
is unchartered, you can choose any design model, you see appropriate.

However, since we are working in an open community, everyone can give
his opinion on this issue. The commenter must definitely back his words
with real arguments. The patch at the top of this thread is such an
argument. You may or may not care about it, at will.

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.
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 seems a bit out-of-date. Here is the output:

build-i386-sony-tx770p$ make
scripts/kconfig/conf -s arch/i386/Kconfig
 CHK include/linux/version.h
 CHK include/linux/utsrelease.h
 CHK include/linux/compile.h
 CC [M]  drivers/misc/tifm_core.o
 CC [M]  drivers/misc/tifm_7xx1.o
 CC [M]  drivers/mmc/tifm_sd.o
drivers/mmc/tifm_sd.c: In function ‘tifm_sd_probe’:
drivers/mmc/tifm_sd.c:987: error: ‘struct mmc_host’ has no member named 
‘max_sectors’

make[2]: *** [drivers/mmc/tifm_sd.o] Error 1
make[1]: *** [drivers/mmc] Error 2
make: *** [drivers] Error 2

This is with v2.6.21 and your tarball unpacked like this:
linux/tifm.h -> include/linux/tifm.h
tifm_sd.c -> drivers/mmc/tifm_sd.c
tifm_7xx1.c -> drivers/misc/tifm_7xx1.c
tifm_core.c -> drivers/misc/tifm_core.c

I will look in mm and write back.
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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 script at

http://bugzilla.kernel.org/attachment.cgi?id=11240&action=view

reliably hangs suspend.

I didn't even see a failure for 'modprove -r tifm', which
doesn't exist in this build.

I will try to bisect git-mmc.patch to locate the source of
trouble. And I will compile my version to check it against
-mm tree.
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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
tifm_core   9876  2 tifm_sd,tifm_7xx1

Since there are [tifm_*] in lsmod; modprobe tifm is no run.

Can you successfully run this test with -mm tree? I that case
the fault may be hardware related.
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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&action=view
-
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: [mmc] alternative TI FM MMC/SD driver for 2.6.21-rc7

[Sergey Yanovich]

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&action=view

in bug 8052
http://bugzilla.kernel.org/show_bug.cgi?id=8052

which seems to be resolved by the patch.

> I don't see any problems on stock 2.6.21.1.


Well, this version seem to ignore cards which are present at
load.

I have this output:
~$ check once
Loading module tifm_sd ...
Checking for a card at /dev/mmcblk0p1 ...
failed.

for this script:
http://bugzilla.kernel.org/attachment.cgi?id=11317&action=view

and you can can see this bug for more details:
http://bugzilla.kernel.org/show_bug.cgi?id=8393

-
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/