From: Rainer Weikusat <rainer.weikusat@sncag.com>
To: Greg KH <greg@kroah.com>
Cc: Rainer Weikusat <rweikusat@sncag.com>,
torvalds@linux-foundation.org, bunk@stusta.de,
linux-kernel@vger.kernel.org
Subject: Re: unfixed regression in 2.6.20-rc6 (since 2.6.19)
Date: Fri, 26 Jan 2007 11:43:22 +0100 [thread overview]
Message-ID: <87y7nq131x.fsf@semtex.sncag.com> (raw)
In-Reply-To: <20070125185101.GA26279@kroah.com> (Greg KH's message of "Thu, 25 Jan 2007 10:51:01 -0800")
Greg KH <greg@kroah.com> writes:
> On Thu, Jan 25, 2007 at 04:20:55PM +0100, Rainer Weikusat wrote:
>> 2.6.19 introduced changes to the UHCI handling of interrupt URBs that
>> caused at least some keyspan USB-to-serial converters to fail,
[...]
> I copied you when this patch was added to my tree,
The only thing I received was a 'this patch has been dropped from
the MM-tree because something happened' message.
> as I had reworked it to be a bit more acceptable (no pointer
> arithmatic, proper coding style, use the newer macros for endpoint
> detection, etc.),
You have basically done a couple of (functionally) totally pointless
changes, like
- not using iterator-style array traversals, but indexed ones
instead
- doing the calculation to determine the endpoint type in
three different places instead of in one place, because the
somewhat silly endpoint classification interfaces enforces
this
- not using a single switch-statement but an if-else-cascade,
again due to limitations of that interface
- replacing the while-loop with an identical for-loop
The net effect of these changes is that an optimizing compiler will
have to work somewhat more to remove all the redundant stuff that
was added. As for 'proper coding style', the code conforms to what is
documented as 'proper kernel coding style'. If this assumption of mine
is incorrect, I'd be happy to hear about reasons why this would be so,
to take them into account for eventual future patches.
> I this patch does not work, please let me know, and I will be glad
> to work to fix it.
I think I'll just resend the working one in this case. But the logic
appears to be identical, so I do not so a reason why it shouldn't.
next prev parent reply other threads:[~2007-01-26 10:44 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-01-25 15:20 unfixed regression in 2.6.20-rc6 (since 2.6.19) Rainer Weikusat
2007-01-25 18:51 ` Greg KH
2007-01-26 10:43 ` Rainer Weikusat [this message]
2007-01-26 17:48 ` Greg KH
2007-01-28 13:34 ` Rainer Weikusat
2007-01-29 1:22 ` Oleg Verych
2007-01-29 23:43 ` Greg KH
2007-01-30 17:40 ` Rainer Weikusat
2007-02-04 4:39 ` Greg KH
2007-02-12 14:30 ` Rainer Weikusat
2007-02-12 16:37 ` Greg KH
2007-02-12 17:10 ` Rainer Weikusat
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=87y7nq131x.fsf@semtex.sncag.com \
--to=rainer.weikusat@sncag.com \
--cc=bunk@stusta.de \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=rweikusat@sncag.com \
--cc=torvalds@linux-foundation.org \
/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