From: Michal Jaegermann <michal@harddata.com>
To: Francois Romieu <romieu@cogenit.fr>
Cc: support <support@promise.com.tw>, Hank <hanky@promise.com.tw>,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 2.4.19-rc2-ac2 pdc202xx.c update
Date: Tue, 23 Jul 2002 11:08:16 -0600 [thread overview]
Message-ID: <20020723110816.A5009@mail.harddata.com> (raw)
In-Reply-To: <20020723091915.A29237@fafner.intra.cogenit.fr>; from romieu@cogenit.fr on Tue, Jul 23, 2002 at 09:19:15AM +0200
On Tue, Jul 23, 2002 at 09:19:15AM +0200, Francois Romieu wrote:
> support <support@promise.com.tw> :
> > We think there is no problems,
>
> After the change, the code is:
>
> if (speed == XFER_UDMA_2)
> OUT_BYTE((thold + adj), indexreg); <- not executed
> OUT_BYTE((IN_BYTE(datareg) & 0x7f), datareg); <- executed, damn it !
I have one more question. Is it really immaterial on the line above in
which order 'datareg' occurences are used? Regardless of what
'OUT_BYTE' is now or may become in the future and how these macro are
used? It looks to me that we are trying to read some byte from
'datareg', clear a bit in it and write it back but looks can be
deceptive. It may turn out that this does or does not work on a
particular compiler whim.
Maybe it is ok now but beeing explicit in a macro definition does
not really cost anything and may save some future grief.
Michal
next prev parent reply other threads:[~2002-07-23 17:05 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <01b801c22f0b$c02cc360$47cba8c0@promise.com.tw>
2002-07-22 3:16 ` [PATCH] 2.4.19-rc2-ac2 pdc202xx.c update support
2002-07-22 6:35 ` Francois Romieu
2002-07-23 1:05 ` support
2002-07-23 7:19 ` Francois Romieu
2002-07-23 17:08 ` Michal Jaegermann [this message]
2002-07-23 10:49 Mikael Pettersson
-- strict thread matches above, loose matches on Subject: below --
2002-07-19 9:09 support
2002-07-19 9:52 ` Giro
2002-07-19 9:56 ` Giro
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=20020723110816.A5009@mail.harddata.com \
--to=michal@harddata.com \
--cc=hanky@promise.com.tw \
--cc=linux-kernel@vger.kernel.org \
--cc=romieu@cogenit.fr \
--cc=support@promise.com.tw \
/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