From: Nathaniel Case <ncase@xes-inc.com>
To: Sebastian Siewior <sebastian@breakpoint.cc>
Cc: linuxppc-dev <linuxppc-dev@ozlabs.org>,
Sebastian Siewior <bigeasy@linutronix.de>,
Greg Kroah-Hartman <gregkh@suse.de>,
linux-usb@vger.kernel.org
Subject: Re: [PATCH 2/2] USB: isp1760: Support board-specific hardware configurations
Date: Thu, 22 May 2008 22:28:37 -0500 [thread overview]
Message-ID: <1211513317.22457.14.camel@satellite> (raw)
In-Reply-To: <20080522153555.GB26410@Chamillionaire.breakpoint.cc>
On Thu, 2008-05-22 at 17:35 +0200, Sebastian Siewior wrote:
> If you don't mind, I would prefer having ISP1760_FLAG_BUS_WIDTH_32 and
> or conditionally HW_DATA_BUS_32BIT.
It doesn't matter much to me -- I just reasoned that a 32-bit bus width
was the norm since it's the hardware default and so having a flags=0
would be desirable for that case. Did you have something else in mind?
> Why do you have to read the chip id here? Is this a dummy read to ensure
> something?
The idea is to force the data bus lines to change states to protect
against a false success. E.g., you read back 0xdeadbabe but it was due
to the line states from the previous write rather than coming from the
chip itself (I've seen this when you get the bus chip select or timing
configuration wrong).
> I'm sorry, you can't solve this way. My ISP1760 claims to be an ISP1761
> this way :) So I end up with one functional port... The only way to
> distinguish between 1760 & 1761 would be at the probing level.
Yikes -- you're right. I would have never guessed that the 1760 would
have returned 0x1761, but sure enough that's what the datasheet says.
Thanks for the feedback.
--
Nate Case <ncase@xes-inc.com>
prev parent reply other threads:[~2008-05-23 3:28 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-21 21:28 [PATCH 2/2] USB: isp1760: Support board-specific hardware configurations Nate Case
2008-05-22 14:28 ` Olof Johansson
2008-05-22 15:35 ` Sebastian Siewior
2008-05-23 3:28 ` Nathaniel Case [this message]
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=1211513317.22457.14.camel@satellite \
--to=ncase@xes-inc.com \
--cc=bigeasy@linutronix.de \
--cc=gregkh@suse.de \
--cc=linux-usb@vger.kernel.org \
--cc=linuxppc-dev@ozlabs.org \
--cc=sebastian@breakpoint.cc \
/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;
as well as URLs for NNTP newsgroup(s).