On Wed, 4 Nov 2009, Alan Cox wrote:
> > >From what I can see, sdio_uart_open() and sdio_uart_activate() are
> > called on the first cat invocation, and then sdio_uart_close() and
> > sdio_uart_shutdown() when cat is stopped with ^C. However neither
>
> I would have expected the cat to termina
The patch titled
msm_sdcc.c: add missing include, fix compilation
has been added to the -mm tree. Its filename is
msm_sdccc-add-missing-include-fix-compilation.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mailin
The patch titled
mmc:: msm_sdcc.c: remove references to htc_pwrsink
has been added to the -mm tree. Its filename is
mmc-msm_sdccc-remove-references-to-htc_pwrsink.patch
Before you just go and hit "reply", please:
a) Consider who else should be cc'ed
b) Prefer to cc a suitable mai
The patch titled
mmc:: msm_sdcc.c: remove references to htc_pwrsink
has been removed from the -mm tree. Its filename was
mmc-msm_sdccc-remove-references-to-htc_pwrsink.patch
This patch was dropped because an updated version will be merged
The current -mm tree may be found at http://us
On Tue, 3 Nov 2009, Alan Cox wrote:
> With the bugs Nicolas reported hopefully now nailed.
Progress, but still not there yet.
I'm still using the same "cat /dev/ttySDIO0" test with a GPS card.
Yanking the card out does terminate the cat process properly. Inserting
the card back in and restart
Jarkko Lavinen wrote:
> Hi Steven
>
> Sorry for late reply.
>
>> It has to reference-count its objects so that they are not freed as long
>> as they are used by upper layers,
>
> The block layer and device removal seems to be designed from
> top-down approach. Althouh disc is referenced from
>
> >From what I can see, sdio_uart_open() and sdio_uart_activate() are
> called on the first cat invocation, and then sdio_uart_close() and
> sdio_uart_shutdown() when cat is stopped with ^C. However neither
I would have expected the cat to terminate when the port is unplugged
(and the uart rem
Add the POSIX block for carrier
Linux TIOCMIWAIT functionality is still lacking from the driver.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 33 -
1 files changed, 32 insertions(+), 1 deletions(-)
diff --git a/drivers/mmc/card/sdio_uart.c b/dr
The new dtr_rts function didn't take the port->func lock as it should
so add use of the lock there.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/drivers/mmc/card/sdio_uart.c b/drivers/mmc/card/sdio_uart.c
Running the current code through checkpatch shows a few bits of noise
mostly but not entirely from before the changes.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 33 +++--
1 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/drivers/mmc
Probably all the tty code should switch to this, especially when the new
lockless kfifo is merged.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 86 +-
1 files changed, 27 insertions(+), 59 deletions(-)
diff --git a/drivers/mmc/card/sdio_
Switching between two non standard baud rates fails because of the cflag
test. Do as we did elsewhere and just kill the "optimisation".
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
diff --git a/drivers/mmc/card/sdio_u
Gets us proper tty semantics, removes some code and fixes up a few corner
case races (hangup during open etc)
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 201 +-
1 files changed, 119 insertions(+), 82 deletions(-)
diff --git a/drivers/mm
When we move to the tty_port logic the port mutex will protect open v close
v hangup. Move to this first in the existing open code so we have a bisection
point.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 20 +---
1 files changed, 9 insertions(+), 11 deletions(-
From: Nicolas Pitre
Now... testing reveals that the very first patch "sdio_uart: use
tty_port" causes a segmentation fault in sdio_uart_open():
Unable to handle kernel NULL pointer dereference at virtual address 0084
pgd = dfb44000 [0084] *pgd=1fb99031, *pte=, *ppte=
Inte
The tty can go away underneath us, so we must refcount it. Do the naïve
implementation initially. We will worry about startup shortly.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 58 ++
1 files changed, 41 insertions(+), 17 deletions(-)
Add a tty_port object to the sdio uart. For the moment just begin using the
tty field of the port, as this is the critical one to clean up.
Signed-off-by: Alan Cox
---
drivers/mmc/card/sdio_uart.c | 41 +++--
1 files changed, 23 insertions(+), 18 deletions(
Move the HUCPL handling from the end of close_port_start to the beginning
of close_port_end. What this actually does is change the ordering from
port shutdown
port->dtr_rts
to
port->dtr_rts
port shutdown
Some hardware drops the physical connection on shutdown so
With the bugs Nicolas reported hopefully now nailed.
---
Alan Cox (10):
sdio_uart: add modem functionality
sdio_uart: Fix the locking on "func" for new code
sdio_uart: Style fixes
sdio_uart: Use kfifo instead of the messy circ stuff
sdio_uart: Fix termios handling
> > sdio_uart_irq
> > sdio_uart_port_remove
> > port->func = NULL;
> > sdio_in
> > BUG_ON
>
> This is actually happening? sdio_claim_host()/sdio_release_host() act
Found by inspection
> like a mutex so sdio_uart
Alan Cox wrote:
>
> The claim method takes the mutex, checks if it is NULL and acts
> accordingly but it releases the mutex, which makes it useless as the code
> then uses port->func. If I move the release of the mutex to the
> release_func method then that fixes almost all cases.
>
> The one I'm
> With this folded in, the card does work with the full series applied.
> However the kernel is now crashing when the card is pulled out while
> some process is reading from the device. This used to behave well
> before. I don't have time to investigate that one right now though.
Going throug
Jean-Christophe PLAGNIOL-VILLARD :
>> + that embeds only one SD/MMC slot.
>> +
>> +config MACH_AT91SAM9G20EK_2MMC
>> +bool "Atmel AT91SAM9G20-EK Evaluation Kit with 2 SD/MMC Slots"
>> +depends on ARCH_AT91SAM9G20
>> +help
>> + Select this if you are using an Atmel AT91SAM9G20-
Hi Steven
Sorry for late reply.
> It has to reference-count its objects so that they are not freed as long
> as they are used by upper layers,
The block layer and device removal seems to be designed from
top-down approach. Althouh disc is referenced from
__blkdev_get(), disc's request queue is
24 matches
Mail list logo
