From: eric@eukrea.com (Eric Bénard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH] otg/ulpi.c : fix register write
Date: Wed, 23 Jun 2010 17:07:49 +0200 [thread overview]
Message-ID: <4C222345.4000902@eukrea.com> (raw)
In-Reply-To: <20100623145816.GE2698@buzzloop.caiaq.de>
Le 23/06/2010 16:58, Daniel Mack a ?crit :
> On Wed, Jun 23, 2010 at 04:50:32PM +0200, Eric B?nard wrote:
>> -static int ulpi_write(struct otg_transceiver *otg, u32 val, u32 reg)
>> +static int ulpi_write(struct otg_transceiver *otg, u32 reg, u32 val)
>
> Urgs. Is this really necessary? It's not that I have a strong opinion
> about the order of arguments in such cases (I kept to the convention
> of __readl() when I wrote it). But _changing_ it like this is really
> confusing. Once in awhile I stumble over such API changes and I always
> wonder about the reason. The problem is that not even the compiler will
> warn you if you got it wrong, when you copied a sniplet from older
> sources etc.
>
> And you really want to break someone knee caps once you find out what
> caused the breakage ;)
>
> So - if we can avoid that, we should do. If anyone speaks up with a real
> reason for changing it, I'd be fine :)
>
No problem if you prefer to keep as it is (this is "cosmetic" but val
and reg are reversed in include/linux/usb/otg.h which I took as the
reference in the present case).
Do you have any opinion on the other part of the patch which removes
ULPI_SET as this prevents to clear bits in the phy register ? If ok for
you, I send a revised patch containing only this change.
Thanks,
Eric
next prev parent reply other threads:[~2010-06-23 15:07 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-06-23 14:50 [PATCH] otg/ulpi.c : fix register write Eric Bénard
2010-06-23 14:58 ` Daniel Mack
2010-06-23 15:07 ` Eric Bénard [this message]
2010-06-23 15:16 ` Igor Grinberg
2010-06-23 15:20 ` Igor Grinberg
2010-06-23 15:22 ` Eric Bénard
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=4C222345.4000902@eukrea.com \
--to=eric@eukrea.com \
--cc=linux-arm-kernel@lists.infradead.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.