mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Greg KH <gregkh@suse.de>, Andi Kleen <ak@suse.de>
Cc: "Lu, Yinghai" <yinghai.lu@amd.com>,
	Stefan Reinauer <stepan@coresystems.de>,
	linuxbios@linuxbios.org, linux-kernel@vger.kernel.org
Subject: Re: [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device
Date: Fri, 01 Dec 2006 14:15:24 -0700	[thread overview]
Message-ID: <m164cvgvwz.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <20061201204249.28842.qmail@cdy.org> (Peter Stuge's message of "Fri, 1 Dec 2006 21:42:49 +0100")

Peter Stuge <stuge-linuxbios@cdy.org> writes:

> On Fri, Dec 01, 2006 at 11:19:16AM -0800, Greg KH wrote:
>> Well, earlyprintk will not work, as you need PCI up and running.
>
> Not all of it though. LinuxBIOS will probably do just enough PCI
> setup to talk to the EHCI controller and use the debug port _very_
> soon after power on.

Right.  For LinuxBIOS not a problem for earlyprintk in the kernel
somethings might need to be refactored.  The challenge in the kernel
is we don't know at build to how to do a pci_read_config...

The other hard part early in the kernel is the fact that the
bar is memory mapped I/O.  Which means it will need to get mapped
into the kernels page tables.

>> And I have some code that barely works for this already, perhaps
>> Eric and I should work together on this :)
>
> I would be interested in having a look at any code for it too.

Sure, I will send it out shortly.  I currently have a working
user space libusb thing (easy, but useful for my debug) and 
a rude read/write to the bar from user space program that
allowed me to debug the worst of the state machine from user
space.  I don't think I have the state setup logic correct yet
but that is minor in comparison.

I really wish the EHCI spec had made that stupid interface 16 bytes
instead of 8 or had a way to chain multiple access together.  The
we could have used a normal usb cable.  As it is most descriptors
are 1 byte to big to read.

>> Yes, that will work just fine today using the usb-serial generic
>> driver.
>
> Ugh. I did not know it was that generic. The irony is that I always
> ask other libusb users to check the kernel drivers to see if they
> really need to write a libusb app.
>
>
>> I'll knock up a "real" driver for the device later today and send
>> it to Linus, as it's trivial to do so, and will make it simpler
>> than using the module parameters.
>
> Awesome. Thanks!

Yep. It looks like it sufficient generic.  The Maximum packet size
appears to be reported correctly for writes which is the tidbit
I was worried about but otherwise it is just a pair of bulk transfer
endpoints.

Eric

  reply	other threads:[~2006-12-01 21:16 UTC|newest]

Thread overview: 29+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-01 18:55 Lu, Yinghai
2006-12-01 19:19 ` Greg KH
2006-12-01 20:42   ` Peter Stuge
2006-12-01 21:15     ` Eric W. Biederman [this message]
2006-12-01 21:46       ` Peter Stuge
2006-12-01 23:02         ` Eric W. Biederman
2006-12-03 17:00           ` Peter Stuge
2006-12-03 23:03             ` Eric W. Biederman
2006-12-01 23:13   ` Eric W. Biederman
2006-12-03 15:49   ` Eric W. Biederman
2006-12-04  5:09     ` [RFC][PATCH 0/2] x86_64 Early usb debug port support Eric W. Biederman
2006-12-04  5:13       ` [RFC][PATCH 1/2] x86_64: Preallocate the fixmap pud and pmd entries Eric W. Biederman
2006-12-04  5:18         ` [RFC][PATCH 2/2] x86_64: earlyprintk usb debug device support Eric W. Biederman
     [not found]       ` <200612042001.09808.david-b@pacbell.net>
2006-12-05 11:01         ` [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support Eric W. Biederman
2006-12-06 17:31           ` Andi Kleen
2006-12-05 11:18         ` Eric W. Biederman
  -- strict thread matches above, loose matches on Subject: below --
2006-12-02  2:43 [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Lu, Yinghai
2006-12-02 14:02 ` Eric W. Biederman
2006-12-02 20:47   ` yhlu
2006-12-03 11:51     ` Eric W. Biederman
2006-12-03 12:01       ` Stefan Reinauer
2006-12-03 12:42         ` Segher Boessenkool
2006-12-03 12:52           ` Stefan Reinauer
2006-12-03 13:11             ` Eric W. Biederman
2006-12-01 22:10 Lu, Yinghai
2006-12-01 18:26 Lu, Yinghai
2006-12-01 18:41 ` Greg KH
2006-12-01 19:04   ` Peter Stuge
2006-12-01 19:17     ` Greg KH

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m164cvgvwz.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linuxbios@linuxbios.org \
    --cc=stepan@coresystems.de \
    --cc=yinghai.lu@amd.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®