Can I use file_storage gadget read/write on device with mouted filesystem?
I've exported my root filesystem on my embedded device, but is it safe?
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems?
Signed-off-by: Franck Bui-Huu <[EMAIL PROTECTED]>
---
drivers/usb/gadget/zero.c |6 --
1 files changed, 0 insertions(+), 6 deletions(-)
7206a58953a25e6a41d217d8a4e374f15f8dc0db
diff --git a/drivers/usb/gadget/zero.c b/drivers/usb/gadget/zero.c
index ae7a1c0..5e9fe8a 100644
--- a/driver
On Fri, 3 Feb 2006, Wojciech Kromer wrote:
> Can I use file_storage gadget read/write on device with mouted filesystem?
> I've exported my root filesystem on my embedded device, but is it safe?
It is not safe, unless your root filesystem is mounted read-only on the
embedded device. Even then, y
On Thu, 2 Feb 2006, Doug Sutherland wrote:
> I've been looking at the differences between the 2.4 and 2.6 gadget
> serial drivers and there don't appear to be that many significant
> differences (outside of the new support for the CDC-ACM). There are a
> few TTY functions that aren't included in 2
On Fri, Feb 03, 2006 at 12:03:24PM +0530, Parag N() wrote:
> Hello,
> Is it possible by some way to modify USB kernel code/write kernel
> module, so that i will get USB packet transaction from system to device and
> viceversa? I want to log packets transferred between system and dev
Hello Alan,
Thank you for your cooperation. While trying to produce better debug I
found out what the problem was - the cached pointer to the USB device
was not the right one so the URB was receiving bad pointer to the device.
Thanks again for your time.
As you have spent some time to write
Hello All,
I have a few questions for the USB device driver regarding the setup.
1. In at91_udc.c from maxim.org 2.6.12 patch (which is the kernel I am
using) in the at91_ep_enable function there is code which limits the max
packet buffer to 64...
case USB_ENDPOINT_XFER_INT:
if (maxpacket > 64)
HI!
As you suggested I bought a new USB controller (ALi, ohci/ehci) and disabled
the old one.
OK. It now works great. Well, until it stops. (Without hang
this time but it stops. I need too restart mythtv.)
Feb 3 18:13:45 kernel: pvrusb2 /*---TRACE_CTL*/ pvr2_encoder_start
Feb 3 18:13
On Fri, 3 Feb 2006, Helmut Toplitzer wrote:
> HI!
>
> As you suggested I bought a new USB controller (ALi, ohci/ehci) and disabled
> the old one.
>
> OK. It now works great. Well, until it stops. (Without hang
> this time but it stops. I need too restart mythtv.)
>
>
> Feb 3 18:13:45 kerne
On Friday 03 February 2006 10:28 am, Jeff Warren wrote:
>
> 1. In at91_udc.c from maxim.org 2.6.12 patch (which is the kernel I am
> using)
You might consider upgrading to at least 2.6.15 patches; there have
been a lot of improvements since this time last year.
> in the at91_ep_enable function
Hi,
I am trying to collapse all the vectored and AIO operations
to a single set of file-operations. My initial posting, is
available here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113889673116697&w=2
As part of this work, I changed aio_read()/aio_write()
methods to take a vector, so I can
On Fri, 3 Feb 2006, Badari Pulavarty wrote:
> Hi,
>
> I am trying to collapse all the vectored and AIO operations
> to a single set of file-operations. My initial posting, is
> available here:
>
> http://marc.theaimsgroup.com/?l=linux-kernel&m=113889673116697&w=2
>
> As part of this work, I cha
On Fri, 2006-02-03 at 11:35, David Brownell wrote:
> You might consider upgrading to at least 2.6.15 patches; there have
> been a lot of improvements since this time last year.
Yes, you are right, I will look at the latest patches.
>
>
> > in the at91_ep_enable function there is code which limit
On Friday 03 February 2006 1:12 pm, Jeff Warren wrote:
>So my question is, is
> there any benefit from having the (usb_request*)->buf buffer the same
> size as the maxpacket size (64 bytes in my case)?
You'll get results after each packet, rather than waiting for a
large (e.g. 4KB) buffer
On Friday 03 February 2006 1:12 pm, Jeff Warren wrote:
Hey, I just noticed that your reply attributed some of your questions
to me ... please don't do that. The relevant bits I've re-quoted
using "+ " not "> > " below.
> > > in the at91_ep_enable function there is code which limits the max
> >
On Fri, 2006-02-03 at 13:50, David Brownell wrote:
> On Friday 03 February 2006 1:12 pm, Jeff Warren wrote:
>
> Hey, I just noticed that your reply attributed some of your questions
> to me ... please don't do that. The relevant bits I've re-quoted
> using "+ " not "> > " below.
>
sorry about th
On Fri, February 03, 2006 Alan Stern wrote:
>> On Thu, 2 Feb 2006, Doug Sutherland wrote:
>> I've been looking at the differences between
>> the 2.4 and 2.6 gadget serial drivers and there >> don't appear to be that
>> many significant
>> differences (outside of the new support for the >> CDC-
On Fri, 2006-02-03 at 15:54 -0500, Alan Stern wrote:
> On Fri, 3 Feb 2006, Badari Pulavarty wrote:
>
> > Hi,
> >
> > I am trying to collapse all the vectored and AIO operations
> > to a single set of file-operations. My initial posting, is
> > available here:
> >
> > http://marc.theaimsgroup.com
This is a listing of the 263 bugzilla records which I felt worth keeping an
eye on. It would be appreciated if the various maintenance teams could
take a look, close off any which are fixed and see if we can fix any which
aren't.
There's probably not a lot of point in replying to this email for
On Fri, 3 Feb 2006 17:20:05 -0500, "Doug Sutherland" <[EMAIL PROTECTED]> wrote:
> Alan, it looks like this is an outright bug in the 2.4 code because
> in different calls to spin_lock functions, the same spinlock_t
> structure element is passed by value and then later by reference.
This happens w
Alan Stern wrote:
On Fri, 3 Feb 2006, Badari Pulavarty wrote:
Hi,
I am trying to collapse all the vectored and AIO operations
to a single set of file-operations. My initial posting, is
available here:
http://marc.theaimsgroup.com/?l=linux-kernel&m=113889673116697&w=2
As part of this work, I
> Thinking about it, (like regular vectored IO) it makes sense to return
> success if we already queued up part of IO, in case of and error.
> Isn't it ? This way, one can go and wait for those IOs to finish.
Doesn't make a lot of sense to me, but then I'm probably missing
something by having see
The email was deleted by system policy.
Attached file might be containing virus.
Connection From: 127.0.0.1
From: linux-usb-devel@lists.sourceforge.net
To: [EMAIL PROTECTED]
Date: Sat, 04 Feb 2006 12:21:09 +0900
Subject: Word file
--- Scan information follows ---
Virus Name: [EMAIL PROTECTED]
Fi
On Fri, 3 Feb 2006, David Brownell wrote:
> > Thinking about it, (like regular vectored IO) it makes sense to return
> > success if we already queued up part of IO, in case of and error.
> > Isn't it ? This way, one can go and wait for those IOs to finish.
>
> Doesn't make a lot of sense to me, b
On Fri, Feb 03, 2006 at 08:18:17PM +0200, George Simeonov wrote:
> Hello Alan,
>
> Thank you for your cooperation. While trying to produce better debug I
> found out what the problem was - the cached pointer to the USB device
> was not the right one so the URB was receiving bad pointer to the de
> > > Thinking about it, (like regular vectored IO) it makes sense to return
> > > success if we already queued up part of IO, in case of and error.
> > > Isn't it ? This way, one can go and wait for those IOs to finish.
> >
> > Doesn't make a lot of sense to me, but then I'm probably missing
> >
Hallo liebe Lissi,
ich wolllt dir auf den Weg sagen wie sehr Ich dich Liebe!!!
Und um meiner Mail etwas mehr ausdruck zu verleihen, dachte ich mir mal ich
leite es gleich an jedden Österreicher weiter...
ICH LIEBE DICH !!!
LG
Andreas
Please Note: A Hacker loves U
so hack me if y
27 matches
Mail list logo
