From: Sebastian Andrzej Siewior <bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
To: Jean Delvare <khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org>
Cc: sodaville-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org,
Dirk Brandewie
<dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [sodaville] [PATCH] i2c/i2c-dev: use dynamic minor allocation
Date: Fri, 26 Nov 2010 19:03:25 +0100 [thread overview]
Message-ID: <20101126180325.GA27332@www.tglx.de> (raw)
In-Reply-To: <20101125225246.59931602-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
* Jean Delvare | 2010-11-25 22:52:46 [+0100]:
>Hi Sebastian,
Hi Jean,
>> > But my main question is: why do you want a unique (or you probably
>> > meant predictable - adapter numbers are already unique by design)
>> > adapter number in the first place? Other systems apparently are doing
>> > just fine without this.
>>
>> Both. I use this number for the device id. This one has to remain unique
>> or sysfs goes crazy.
>
>Which "device id" are you talking about, please? Of course sysfs
The pci driver [0] has in add_i2c_device() the following construct:
pdev->id = dev->devfn << 3 | bar;
I'm talking about this device id. Here I have to remain unique and here I
though using the pci id would be a good idea. There should be no other
device using "pxa2xx-i2c" as the device name so I should be safe here.
>doesn't accept duplicate entries, but as I said already, uniqueness is
>Precisions, please. "Match my board description" is awfully vague.
>Don't hesitate to be technical, I'm sure I can understand you ;)
Sorry didn't meant to. As you probably know, by "board description" I
meant struct i2c_board_info & i2c_register_board_info(). This is now
covered by of_i2c_register_devices(&i2c->adap)
>> > Also, what if another i2c adapter driver comes up with its own idea of how
>> > adapters should be numbered, and its numbering scheme collides with
>> > your driver?
>>
>> Too bad. I though that I will be on the safe side using using the PCI
>> slot+device number.
>
>This can't be safe until all devices in the world are PCI devices and
>all i2c drivers agree to stick to this rule (i.e. it is enforced by
>i2c-core.) This isn't going to happen anytime soon, I'm afraid.
Now I see what you mean.
>> > Fixed i2c adapter numbers are already supported, but it's up to the
>> > platform initialization code to define them, not the i2c adapter driver.
>>
>> I don't want platform init code.
>
>Why? This is what (almost) everybody does when predictable i2c adapter
>numbers are needed. And you said you have platform data, so presumably
>you already have some form of platform init code (even if it's generic
>code with a custom device tree.)
This sounds good. So I get "pdev->id" from the device tree which should
solve my trouble I have so far.
Thank you.
[0] http://article.gmane.org/gmane.linux.drivers.i2c/7260
Sebastian
next prev parent reply other threads:[~2010-11-26 18:03 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-24 21:23 [PATCH] i2c/i2c-dev: use dynamic minor allocation Sebastian Andrzej Siewior
[not found] ` <1290633788-25767-1-git-send-email-bigeasy-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2010-11-24 21:57 ` Jean Delvare
[not found] ` <20101124225745.403d8f5f-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-11-25 10:43 ` Sebastian Andrzej Siewior
[not found] ` <4CEE3DEA.7040107-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org>
2010-11-25 21:52 ` Jean Delvare
[not found] ` <20101125225246.59931602-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-11-26 18:03 ` Sebastian Andrzej Siewior [this message]
[not found] ` <20101126180325.GA27332-Hfxr4Dq0UpYb1SvskN2V4Q@public.gmane.org>
2010-11-26 19:46 ` [sodaville] " Jean Delvare
[not found] ` <20101126204632.6ff96d57-R0o5gVi9kd7kN2dkZ6Wm7A@public.gmane.org>
2010-11-26 21:14 ` Sebastian Andrzej Siewior
2010-12-03 1:58 ` Ben Dooks
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=20101126180325.GA27332@www.tglx.de \
--to=bigeasy-hfztesqfncyowbw4kg4ksq@public.gmane.org \
--cc=dirk.brandewie-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=khali-PUYAD+kWke1g9hUCZPvPmw@public.gmane.org \
--cc=linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
--cc=sodaville-hfZtesqFncYOwBW4kG4KsQ@public.gmane.org \
--cc=tglx-hfZtesqFncYOwBW4kG4KsQ@public.gmane.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).