mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: David Brownell <david-b@pacbell.net>
Cc: linux-usb-devel@lists.sourceforge.net,
	Peter Stuge <stuge-linuxbios@cdy.org>,
	Stefan Reinauer <stepan@coresystems.de>, Greg KH <gregkh@suse.de>,
	linux-kernel@vger.kernel.org, "Lu, Yinghai" <yinghai.lu@amd.com>,
	Andi Kleen <ak@suse.de>,
	linuxbios@linuxbios.org
Subject: Re: [linux-usb-devel] [RFC][PATCH 0/2] x86_64 Early usb debug port support.
Date: Tue, 05 Dec 2006 04:18:30 -0700	[thread overview]
Message-ID: <m1fybu7fqx.fsf@ebiederm.dsl.xmission.com> (raw)
In-Reply-To: <200612042001.09808.david-b@pacbell.net> (David Brownell's message of "Mon, 4 Dec 2006 20:01:08 -0800")

David Brownell <david-b@pacbell.net> 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 the windows drivers are
>> using these debug devices.
>
> I'm glad to see someone finally got progress on this ... :)
>
> Separately, I forwarded some stuff I did last year ... maybe it'll help.
> You seem to have gotten further.  Have you also observed that the
> NetChip device seems to have polarity issues, such that only one
> end behaves properly?

I haven't yet.  But I don't think I have actually tried turning
the cable around in a very meaningful way yet either.  Possibly
this is something that has been fixed.  I know there are some
odd issues that I have encountered.  Like occasionally I would
need to stop the software on one side, or I would need to unplug
it when things got sufficiently confused.

> Note that this should **NOT** be specific to x86_64, since pretty
> much any PCI based EHCI can do this.  I wouldn't be able to use
> this on my NForce2 box, for example ...

So I took a quick look what it would take to do this truly generically
and even initializing this generally when console code typically
is registered looks like a problem.  Although only because we don't
get around to setting up pci_config space access helpers in a timely
manner.  To some extent that still sucks because you are still being
initialized before the general ehci-hcd code.

Regardless an arch specific i386 variant was easy to throw together.
It still needs a bit of work but it basically worked.

> As for EHCI registers, if this really _needs_ to live outside
> of drivers/usb/host, then I'd suggest <linux/usb/ehci.h> for
> the relevant declarations ... the <linux/usb/*.h> headers are
> provided exactly for sharing such declaration between otherwise
> unrelated parts of the tree.

Yep that sounds like the right thing to do.  I think I at least
need to be called from something outside of drivers/usb and may
need the code there.

Doing this in a truly generic fashion looks like a major pain.
Because all of the infrastructure needs to be fixed.

Eric

  parent reply	other threads:[~2006-12-05 22:59 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-12-01 18:55 [LinuxBIOS] #57: libusb host program for PLX NET20DC debug device Lu, Yinghai
2006-12-01 19:19 ` Greg KH
2006-12-01 20:42   ` Peter Stuge
2006-12-01 21:15     ` Eric W. Biederman
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 [this message]
2006-12-06 20:43 Lu, Yinghai
2006-12-06 20:58 ` Andi Kleen
2006-12-06 21:12   ` Eric W. Biederman
2006-12-06 21:17   ` David Brownell
2006-12-06 21:24     ` Andi Kleen
2006-12-06 21:37       ` Eric W. Biederman
2006-12-06 21:59         ` Andi Kleen
2006-12-06 23:47       ` David Brownell
2006-12-06 21:08 Lu, Yinghai

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=m1fybu7fqx.fsf@ebiederm.dsl.xmission.com \
    --to=ebiederm@xmission.com \
    --cc=ak@suse.de \
    --cc=david-b@pacbell.net \
    --cc=gregkh@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-usb-devel@lists.sourceforge.net \
    --cc=linuxbios@linuxbios.org \
    --cc=stepan@coresystems.de \
    --cc=stuge-linuxbios@cdy.org \
    --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®