From: peter.korsgaard@barco.com (Peter Korsgaard)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver
Date: Wed, 24 Oct 2012 13:45:58 +0200 [thread overview]
Message-ID: <87objsqeix.fsf@thor.barco.com> (raw)
In-Reply-To: <5087A8E5.8050103@free-electrons.com> (Maxime Ripard's message of"Wed, 24 Oct 2012 10:37:57 +0200")
>>>>> "MR" == Maxime Ripard <maxime.ripard@free-electrons.com> writes:
Hi,
MR> +* Standard I2C mux properties. See mux.txt in this directory.
MR> +* I2C child bus nodes. See mux.txt in this directory.
MR> +
MR> +Optional properties:
MR> +- idle-state: value to set to the muxer when idle. When no value is
>>
>> How about 'bitmask defining mux state when idle' instead?
MR> Since the array documented as using the bitmasks in the platform_data
MR> and described as an array of bitmasks is called "values", and the file
MR> mux.txt talks about "numbers" to put into reg, won't this be confusing
MR> to have three names for the exact same thing?
Yeah, the mess is less than perfect. To my defense I did use bitmask in
the platform data documentation:
@values: Array of bitmasks of GPIO settings (low/high) for each position
@idle: Bitmask to write to MUX when idle or GPIO_I2CMUX_NO_IDLE if not used
But ok, I don't feel strongly about it.
>> Why this change? I don't see why it is needed and the patch would be a
>> lot easier to review without all the s/.data/->data/ noise.
MR> Ah yes, since mux is already allocated using kcalloc, we don't need to
MR> do it for data as well. I will remove it.
Ok, great.
--
Sorry about disclaimer - It's out of my control.
Bye, Peter Korsgaard
DISCLAIMER:
Unless indicated otherwise, the information contained in this message is privileged and confidential, and is intended only for the use of the addressee(s) named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any dissemination, distribution or copying of this message and/or attachments is strictly prohibited. The company accepts no liability for any damage caused by any virus transmitted by this email. Furthermore, the company does not warrant a proper and complete transmission of this information, nor does it accept liability for any delays. If you have received this message in error, please contact the sender and delete the message. Thank you.
next prev parent reply other threads:[~2012-10-24 11:45 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-22 12:53 [PATCHv5 0/2] ARM: I2C: Add device tree bindings to i2c-mux-gpio Maxime Ripard
2012-10-22 12:53 ` [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver Maxime Ripard
2012-10-22 20:16 ` Stephen Warren
2012-10-23 19:51 ` Peter Korsgaard
2012-10-24 8:37 ` Maxime Ripard
2012-10-24 11:45 ` Peter Korsgaard [this message]
2012-10-22 12:53 ` [PATCH 2/2] ARM: dts: cfa10049: Add the i2c muxer buses to the CFA-10049 Maxime Ripard
-- strict thread matches above, loose matches on Subject: below --
2012-10-25 16:23 [PATCHv7 0/2] ARM: I2C: Add device tree bindings to i2c-mux-gpio Maxime Ripard
2012-10-25 16:23 ` [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver Maxime Ripard
2012-11-16 8:30 ` Wolfram Sang
2012-10-24 14:40 [PATCHv6 0/2] ARM: I2C: Add device tree bindings to i2c-mux-gpio Maxime Ripard
2012-10-24 14:40 ` [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver Maxime Ripard
2012-10-24 14:56 ` Peter Korsgaard
2012-10-18 14:13 [PATCHv4 0/2] ARM: I2C: Add device tree bindings to i2c-mux-gpio Maxime Ripard
2012-10-18 14:13 ` [PATCH 1/2] i2c: mux: Add dt support to i2c-mux-gpio driver Maxime Ripard
2012-10-18 22:36 ` Stephen Warren
2012-10-19 8:55 ` Maxime Ripard
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=87objsqeix.fsf@thor.barco.com \
--to=peter.korsgaard@barco.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 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).