the next block write and will fail (it seems to fail on my card). It
seems strange to change the register address ?
This also relates to byte mode.
What do you think ?
Also, do you have a bug reporting procedure for mmc-git tree ?
Regards,
Dean.
--
Dean Jenkins
Embedded Software Engineer
d
anywhere ?
Thanks,
Regards,
Dean.
On Tue, 2007-11-20 at 11:58 +0100, Pierre Ossman wrote:
> On Mon, 19 Nov 2007 11:44:54 +
> Dean Jenkins <[EMAIL PROTECTED]> wrote:
>
> > This E-mail is for the attention of Pierre Ossman (MMC sub-system
> > maintainer)
>
eb(func, x, 0x08, &ret);
}
/* restore to original function number */
func->num = old_num;
...
Regards,
Dean.
On Tue, 2007-11-20 at 11:51 +0100, Pierre Ossman wrote:
> On Tue, 20 Nov 2007 10:28:53 +
> Dean Jenkins <[EMAIL PROTECTED]> wrote:
>
>
n a manner that needs the START ADDRESS to be
changed by the core driver ?
Regards,
Dean.
On Tue, 2007-11-20 at 15:10 +0100, Pierre Ossman wrote:
> On Tue, 20 Nov 2007 12:26:11 +0000
> Dean Jenkins <[EMAIL PROTECTED]> wrote:
>
> > Hi Pierre,
> >
> > IMHO the iss
.
Regards,
Dean.
On Wed, 2007-11-21 at 14:08 +0100, Pierre Ossman wrote:
> On Wed, 21 Nov 2007 11:57:01 +
> Dean Jenkins <[EMAIL PROTECTED]> wrote:
>
> > Hi Pierre,
> >
> > I've looked at the SD Card Association's SDIO Part E1 V2.00
> > spec
ode" while loop (with the "fix") and the "byte
mode" while loop (without the "fix"). The "byte mode" while loop has a
hard coded value of 1 for the blocks parameter. So the bug is masked. As
I said above, I think the "byte mode" should use a valu
at 12:42 +0100, Pierre Ossman wrote:
> On Thu, 22 Nov 2007 10:41:43 +
> Dean Jenkins <[EMAIL PROTECTED]> wrote:
>
> > Hi Pierre,
> >
> > I've been checking my SDIO CMD53 data transfers and I notice the
> > following:
> >
> > block size
sl_encaps() and slip_write_wakeup() do not handle
error codes from tty->ops->write() and a recursive stack overflow crash
can occur if the tty->ops->write() fails to write all the characters. I
have some patches to fix this but would like some feedback on an
appropriate solution.
T
Hi Peter,
On 24/06/13 14:53, Peter Hurley wrote:
On 06/24/2013 04:27 AM, Dean Jenkins wrote:
Hi,
Using the Linux v3.9 tag, I note that
./scripts/get_maintainer.pl -f drivers/net/slip/slip.c
net...@vger.kernel.org (open list:NETWORKING DRIVERS)
linux-kernel@vger.kernel.org (open list)
There
ocalhost kernel: RSP
Jun 25 12:52:32 localhost kernel: ---[ end trace f219a9b765a4acc9 ]---
Jun 25 12:52:52 localhost vmnetBridge: Removing interface eth0 index:2
Jun 25 12:52:52 localhost vmnetBridge: RTM_NEWLINK: name:eth0 index:2
flags:0x00011043
Jun 25 12:52:52 localhost vmnetBridge: Adding
On 02/07/13 12:02, Andre Naujoks wrote:
On 02.07.2013 11:39, schrieb Dean Jenkins:
On 01/07/13 15:49, Andre Naujoks wrote:
Hello.
This patch removes the direct call to tty_wakeup in pty_write. I have
not noticed any drawbacks with this but I am not familiar with the pty
driver at all. I think
to pty_write(). Probably,
pty_write() should not call tty_wakeup() but safer to modify SLIP rather
than the PTY/TTY layer.
Thanks,
Dean Jenkins
Mentor Graphics
--
1.8.1.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message
.
Signed-off-by: Dean Jenkins
---
net/bluetooth/rfcomm/tty.c | 14 +-
1 file changed, 13 insertions(+), 1 deletion(-)
diff --git a/net/bluetooth/rfcomm/tty.c b/net/bluetooth/rfcomm/tty.c
index b6e44ad..56d28d1 100644
--- a/net/bluetooth/rfcomm/tty.c
+++ b/net/bluetooth/rfcomm/tty.c
take place per
SLIP frame. This could cause missing or truncated SLIP frames to
be transmitted when the write() function fails to write the complete
frame. In other words the TTY wakeup event does nothing because
the TTY_DO_WRITE_WAKEUP flag has been cleared.
Signed-off-by: Dean Jenkins
---
dr
corruption of the sent data length.
Note that SLIP is connectionless so on TTY error indicate that all data
was sent. It seems SLIP does not return error codes to the network
layer.
Signed-off-by: Dean Jenkins
---
drivers/net/slip/slip.c | 26 ++
1 file changed, 22
-by: Dean Jenkins
---
drivers/net/slip/slip.c | 29 -
1 file changed, 20 insertions(+), 9 deletions(-)
diff --git a/drivers/net/slip/slip.c b/drivers/net/slip/slip.c
index e2eff84..0ded23d 100644
--- a/drivers/net/slip/slip.c
+++ b/drivers/net/slip/slip.c
@@ -404,15
Add a printk to show when xleft is non-zero in sl_encaps.
The idea is to see whether a previous SLIP frame failed to be
fully transmitted.
Signed-off-by: Dean Jenkins
---
drivers/net/slip/slip.c | 4
1 file changed, 4 insertions(+)
diff --git a/drivers/net/slip/slip.c b/drivers/net/slip
could upload my SLIP patches to the
linux-kernel mailing list.
Regards,
Dean Jenkins
Mentor Graphics
--
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/
On 20/03/14 19:30, Felipe Balbi wrote:
LDISCs shouldn't call tty->ops->write() from within
->write_wakeup().
->write_wakeup() is called with port lock taken and
IRQs disabled, tty->ops->write() will try to acquire
the same port lock and we will deadlock.
I think the work queue should be placed
cancel work in that case).
I agree with your statement.
Regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
a is not always aligned
to the start of the URB buffer.
I agree that your environment may never suffer from lost URBs so removal
of the patch would work OK.
I will try to find some time to setup a test environment.
Regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation
On 05/05/16 00:45, John Stultz wrote:
On Tue, May 3, 2016 at 3:54 AM, Dean Jenkins wrote:
On 03/05/16 11:04, Guodong Xu wrote:
did you test on ARM 64-bit system or ARM 32-bit? I ask because HiKey
is an ARM 64-bit system. I suggest we should be careful on that. I saw
similar issues when
he
tests to see whether anything improved.
In other words, you need to eliminate the dmesg messages saying "not
running at top speed; connect to a high speed hub".
Best regards,
Dean
-Guodong Xu
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
the suggestion but I hope USB high speed (480Mbps)
operation was the intended environment rather than the useless USB full
speed (12Mbps) operation.
Let's hope that not using the USB hub improves things.
Regards,
Dean
Andrew
--
Dean Jenkins
Embedded Software Engineer
Linux Transp
of 1500 is not exceeded.
The commit only runs when Ethernet frames span URBs which typically
occurs when IP fragmentation happens or when there is a very high rate
of Ethernet frames per second.
At least, it is now clear why you see "988 remaining", that is because
you are using m
ave any
links to websites that sell your device ?
Are you using UDP or TCP connections ?
Regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
On 03/05/16 11:04, Guodong Xu wrote:
On 3 May 2016 at 17:23, Dean Jenkins wrote:
On 03/05/16 05:55, John Stultz wrote:
In testing with HiKey, we found that since commit 3f30b158eba5c60
(asix: On RX avoid creating bad Ethernet frames), we're seeing lots of
noise during network tran
"ping -f -c 200 -s $packet_length $ip_address" to load up
the USB link.
Seems that I need kernel v4.4 or later to get a kernel with my patch in.
This will take me a few days to find time to rig something up to test...
Regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
ug logic to check those offset calculation used
to find rx->header, the one in problematic code is always too
large by sizeof(u32).
Thus, this patch removes the incorrect " + sizeof(u32)" addition
in the problematic calculation, and resolves the issue.
Cc: Dean Jenkins
Cc: "David
ansmission is prevented.
It is possible that my commits might have been too robust so perhaps
some simplification is possible.
Feel free to send me further questions about my commits. I will try to
answer your queries within a couple of days each time.
Regards,
Dean
--
Dean Jenkins
Embedded Software Engineer
Linux Transportation Solutions
Mentor Embedded Software Division
Mentor Graphics (UK) Ltd.
30 matches
Mail list logo
