On Wednesday 06 December 2006 1:24 pm, Andi Kleen wrote:
> > - Host, to which that console connects (through the debug device);
> > runs usb_debug, much like any other usb-serial device
>
> My understanding was that the client could run in user
> space only on top of libusb.
I suppose it c
> > However I suppose it would be ok to switch Eric's code between early
> > pci access and locked one once the PCI subsystem is up and running.
> > Just don't forget bust_spinlocks()
>
> No pci access on that path.
Hmm good point. Ok ignore that then.
keep should be default then.
-Andi
-
To u
Andi Kleen <[EMAIL PROTECTED]> writes:
> \
>> - Host, to which that console connects (through the debug device);
>> runs usb_debug, much like any other usb-serial device
>
> My understanding was that the client could run in user
> space only on top of libusb.
Looks like a normal serial por
\
> - Host, to which that console connects (through the debug device);
> runs usb_debug, much like any other usb-serial device
My understanding was that the client could run in user
space only on top of libusb.
>
> It's analagous to debugging an embedded box using a serial console
> with
> > or usb_debug that Greg just added
>
> Ah I didn't notice that. If there is a usb_debug that works later
> then yes it would need to be disabled.
I detect confusion here ... remember that there are potentially two
distinct Linux systems involved here:
- Target, with some kind of console hoo
Andi Kleen <[EMAIL PROTECTED]> writes:
> On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
>> -Original Message-
>> From: Andi Kleen [mailto:[EMAIL PROTECTED]
>> Sent: Wednesday, December 06, 2006 9:31 AM
>>
>> >Also for usb console keep should be made default because the output
>>
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 12:59 PM
>I haven't looked how the other usb_debug works -- if it's polled
>too then it wouldn't have much advantage.
Need to verify if the two sides of debug cable are identical.
>And it w
On Wednesday 06 December 2006 21:43, Lu, Yinghai wrote:
> -Original Message-
> From: Andi Kleen [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 06, 2006 9:31 AM
>
> >Also for usb console keep should be made default because the output
> won't
> >be duplicated.
>
> Still need to tx_r
-Original Message-
From: Andi Kleen [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 06, 2006 9:31 AM
>Also for usb console keep should be made default because the output
won't
>be duplicated.
Still need to tx_read to make console can take command?
Or transfer to generic usb_serial o
On Tuesday 05 December 2006 12:01, Eric W. Biederman wrote:
>
> Ok due to popular demands here is the slightly fixed patch that works
> on both i386 and x86_64. For the i386 version you must not have
> HIGHMEM64G enabled.
>
> I just rolled it all into one patch as I'm to lazy to transmit all
>
David Brownell <[EMAIL PROTECTED]> writes:
> On Sunday 03 December 2006 9:09 pm, Eric W. Biederman wrote:
>>
>> My driver should be sufficient to work with any EHCI in a realatively
>> clean state, and needs no special BIOS support just the hardware.
>> This appears to be different than the way th
Ok due to popular demands here is the slightly fixed patch that works
on both i386 and x86_64. For the i386 version you must not have
HIGHMEM64G enabled.
I just rolled it all into one patch as I'm to lazy to transmit all
3 of them.
Eric
arch/i386/kernel/head.S |8 +
arch/x86_64
12 matches
Mail list logo
