From: Jaswinder Singh <jaswinder.singh@linaro.org>
To: andy.green@linaro.org
Cc: Andy Green <andy@warmcat.com>,
Linux USB list <linux-usb@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>,
broonie@opensource.wolfsonmicro.com, roger.quadros@nokia.com,
greg@kroah.com, benh@kernel.crashing.org,
grant.likely@secretlab.ca,
Nicolas Pitre <nicolas.pitre@linaro.org>
Subject: Re: RFC: Platform data for onboard USB assets
Date: Tue, 22 Mar 2011 20:35:40 +0530 [thread overview]
Message-ID: <AANLkTikEtneWEu4iQgfKw-zkAT3Z=e7ohXgDq7oJAQvv@mail.gmail.com> (raw)
In-Reply-To: <4D79F068.2080009@linaro.org>
[CC'ed interested parties in retrospect and resent in plain text]
On 11 March 2011 15:20, Andy Green <andy@warmcat.com> wrote:
>
> Hi -
>
> platform_data is a well established way in Linux to pass configuration data up to on-board assets from a machine file like mach-xyz.c. It's also supported to pass platform_data up to devices that are probed asynchronously from busses like i2c as well, which is very handy.
>
> However AFAIK it's not possible to bind platform_data to probed USB devices as it stands.
>
> There are now boards which have on-board USB assets, for example OMAP4 Panda which has a USB <-> Ethernet bridge wired up permanently. It'd be convenient to also be able to pass optional platform_data to these devices when they are asynchronously probed.
>
> So what's the feeling about a new api to register an array of platform_data pointers bound to static "devpath" names in the machine file?
>
> When a usb device is instantiated, it can check through this array if it exists, matching on devname, and attach the platform_data to the underlying probed usb device's dev->platform_data, which it seems is currently unused.
>
> The particular use that suggested this is on Panda, it would be ideal to be able to set a flag in the usb device's platform data that forces it to be named eth%d since it's a hardwired asset on the board with an RJ45 socket.
>
> Comments, implementation suggestions, enquiries as to my level of crack consumption etc welcomed ^^
Hi Andy,
Personally, I wouldn't have bothered thinking about some kernel-wide
solution to the Panda SMSC9514 issue. I think defining Panda specific
udev rules to 'rename the SMSC9614 on USB1(?) to ETH0' is sufficient and
legal to do. Bus enumeration algos change neither often nor enough.
I believe there would be far riskier assumptions in filesystems already.
But I do agree it is nice to have system wide solutions whenever due.
Like this attempted patchset. Which is based upon two questions :-
Q(a) Can discoverable buses(USB, SDIO etc) legally need platform_data
or similar?
Q(b) If yes, what 'key' is most suitable for identifying the right device
to attach the data to ?
(a) We already have a good example, of Panda's missing MAC. I am sure there
would be more to think of.
Though it is illegal for a NIC to not have MAC address, no spec demands the
MAC be on some EEPROM or like. Theoretically, the NIC vendor could
hand me a NIC
and a note with it's unique MAC address scribbled :)
As Mark already noted, savings pile if we could save eeproms when a device is
expected to ship in tens of thousands.
IIANM, Greg acknowledged passing MAC via board specific data
structure(albeit via DT)
It's a different matter that DT has many hearts to win(at least in ARM Linux)
So, perhaps the answer to Q(a) is - Yes.
(b) IMHO, though stable enough, the most obvious method of 'devpath association'
is indeed not future-proof.
Having parent pointers to compare sounds like a bit too intrusive.
People might want to suggest?
Thanks.
next prev parent reply other threads:[~2011-03-22 15:05 UTC|newest]
Thread overview: 156+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-11 9:50 RFC: Platform data for onboard USB assets Andy Green
2011-03-11 12:31 ` Arnd Bergmann
2011-03-11 12:44 ` Andy Green
2011-03-11 14:42 ` Roger Quadros
2011-03-11 15:12 ` Roger Quadros
2011-03-11 15:22 ` Arnd Bergmann
2011-03-11 15:50 ` Roger Quadros
2011-03-11 15:55 ` Arnd Bergmann
2011-03-11 15:29 ` Mark Brown
2011-03-11 15:54 ` Arnd Bergmann
2011-03-11 16:03 ` Mark Brown
2011-03-11 16:14 ` Greg KH
2011-03-11 16:27 ` Mark Brown
2011-03-11 16:35 ` Greg KH
2011-03-11 16:48 ` Mark Brown
2011-03-11 16:56 ` Greg KH
2011-03-11 17:08 ` Mark Brown
2011-03-11 17:23 ` Greg KH
2011-03-11 17:41 ` Mark Brown
2011-03-17 2:14 ` Nicolas Pitre
2011-03-17 20:13 ` Greg KH
2011-03-17 20:18 ` Mark Brown
2011-03-17 20:26 ` Greg KH
2011-03-17 21:24 ` Mark Brown
2011-03-17 21:31 ` Greg KH
2011-03-17 21:40 ` Mark Brown
2011-03-17 21:47 ` Greg KH
2011-03-17 22:33 ` Arnd Bergmann
2011-03-17 22:53 ` Greg KH
2011-03-17 23:18 ` Andy Green
2011-03-17 23:25 ` Greg KH
2011-03-18 7:42 ` Andy Green
2011-03-18 22:54 ` Benjamin Herrenschmidt
2011-03-18 22:57 ` Andy Green
2011-03-18 4:54 ` Grant Likely
2011-03-18 8:19 ` Arnd Bergmann
2011-03-17 23:22 ` Andy Green
2011-03-18 15:00 ` Arnd Bergmann
2011-03-18 15:15 ` Mark Brown
2011-03-18 17:52 ` Andy Green
2011-03-18 18:20 ` David Anders
2011-03-18 18:25 ` Mark Brown
2011-03-18 20:02 ` Andy Green
2011-03-18 21:11 ` Arnd Bergmann
2011-03-18 21:17 ` Andy Green
2011-03-18 20:06 ` Arnd Bergmann
2011-03-18 21:33 ` Andy Green
2011-03-18 23:25 ` Mark Brown
2011-03-18 23:33 ` Andy Green
2011-03-18 21:36 ` Grant Likely
2011-03-18 22:47 ` Benjamin Herrenschmidt
2011-03-18 21:28 ` Grant Likely
2011-03-18 23:04 ` Andy Green
2011-03-18 22:37 ` Benjamin Herrenschmidt
2011-03-18 22:39 ` Andy Green
2011-03-17 23:27 ` Grant Likely
2011-03-18 7:49 ` Andy Green
2011-03-18 8:25 ` Arnd Bergmann
2011-03-18 8:38 ` Andy Green
2011-03-17 22:11 ` Arnd Bergmann
2011-03-17 22:20 ` Greg KH
2011-03-18 8:42 ` Roger Quadros
2011-03-18 9:01 ` Arnd Bergmann
2011-03-18 9:55 ` Roger Quadros
2011-03-18 10:09 ` Andy Green
2011-03-17 21:03 ` Nicolas Pitre
2011-03-17 21:32 ` Greg KH
2011-03-11 16:26 ` Andy Green
2011-03-11 16:45 ` Alan Stern
2011-03-11 16:51 ` Andy Green
2011-03-11 17:08 ` Greg KH
2011-03-11 18:09 ` Andy Green
2011-03-11 19:12 ` Alan Stern
2011-03-11 20:05 ` Andy Green
2011-03-11 20:21 ` Greg KH
2011-03-11 21:07 ` Andy Green
2011-03-11 21:44 ` Greg KH
2011-03-11 22:24 ` Andy Green
2011-03-12 16:00 ` Alan Stern
2011-03-12 23:02 ` Andy Green
2011-03-11 19:37 ` Greg KH
2011-03-11 16:53 ` Mark Brown
2011-03-11 16:08 ` Greg KH
2011-03-11 16:20 ` Andy Green
2011-03-11 16:36 ` Greg KH
2011-03-11 16:41 ` Andy Green
2011-03-11 22:07 ` Benjamin Herrenschmidt
2011-03-11 21:52 ` Benjamin Herrenschmidt
2011-03-11 22:45 ` Grant Likely
2011-03-11 22:47 ` Andy Green
2011-03-11 23:39 ` Grant Likely
2011-03-14 14:54 ` Arnd Bergmann
2011-03-22 15:05 ` Jaswinder Singh [this message]
2011-03-22 16:04 ` Andy Green
2011-03-22 18:19 ` Jaswinder Singh
2011-03-22 18:37 ` Andy Green
2011-03-22 18:59 ` Jaswinder Singh
2011-03-22 19:35 ` Andy Green
[not found] ` <AANLkTim=ezye=1fQP_1a2SWbPnbENP9B+k27Z3AkS=zf@mail.gmail.com>
2011-03-22 15:12 ` Mark Brown
2011-03-22 15:23 ` Jaswinder Singh
2011-03-24 18:56 ` Grant Likely
2011-03-22 21:08 ` Benjamin Herrenschmidt
2011-03-22 22:37 ` Andy Green
2011-03-23 1:03 ` Benjamin Herrenschmidt
2011-03-23 2:26 ` Nicolas Pitre
2011-03-23 3:23 ` Benjamin Herrenschmidt
2011-03-23 4:21 ` Nicolas Pitre
2011-03-23 4:56 ` Greg KH
2011-03-23 5:44 ` Benjamin Herrenschmidt
2011-03-23 9:38 ` Alan Cox
2011-03-23 10:53 ` Mark Brown
2011-03-23 15:04 ` Greg KH
2011-03-23 15:10 ` Mark Brown
2011-03-23 15:24 ` Andy Green
2011-03-23 15:45 ` Arnd Bergmann
2011-03-23 15:38 ` Nicolas Pitre
2011-03-23 9:31 ` Andy Green
2011-03-23 9:47 ` Alan Cox
2011-03-23 10:06 ` Andy Green
2011-03-23 10:32 ` Arnd Bergmann
2011-03-23 10:39 ` Andy Green
2011-03-23 10:56 ` Alan Cox
2011-03-23 11:13 ` Andy Green
2011-03-23 11:34 ` Alan Cox
2011-03-23 12:02 ` Andy Green
2011-03-23 15:08 ` Greg KH
2011-03-23 16:12 ` Arnd Bergmann
2011-03-23 16:22 ` Greg KH
2011-03-23 16:34 ` Andy Green
2011-03-23 16:56 ` [RFC] usbnet: use eth%d name for known ethernet devices Arnd Bergmann
2011-03-23 17:04 ` Andy Green
2011-03-23 17:11 ` Arnd Bergmann
2011-03-24 10:45 ` Andy Green
2011-03-23 17:13 ` Arnd Bergmann
2011-03-23 17:54 ` David Anders
2011-03-23 18:46 ` Greg KH
2011-03-23 19:35 ` Arnd Bergmann
[not found] ` <AANLkTim7hPfTv3gDYnh+jGxHBg0OvX=r1FKYoHnH7H_o@mail.gmail.com>
2011-03-23 19:57 ` Arnd Bergmann
2011-03-23 19:59 ` Randy Dunlap
2011-03-23 23:17 ` Michal Nazarewicz
2011-03-23 23:19 ` Randy Dunlap
2011-03-23 23:38 ` Steve Calfee
2011-03-24 0:01 ` Ben Hutchings
2011-03-24 13:13 ` Arnd Bergmann
2011-03-24 13:15 ` Arnd Bergmann
2011-03-24 13:44 ` Andy Green
2011-03-24 13:56 ` Alan Stern
2011-03-24 17:20 ` Alexey Orishko
2011-03-25 11:57 ` Arnd Bergmann
2011-03-25 16:26 ` Alexey Orishko
2011-03-25 16:43 ` Arnd Bergmann
2011-03-24 19:17 ` RFC: Platform data for onboard USB assets Grant Likely
2011-03-24 20:10 ` Andy Green
2011-03-23 14:55 ` Nicolas Pitre
2011-03-23 10:22 ` Benjamin Herrenschmidt
2011-03-23 15:11 ` Nicolas Pitre
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='AANLkTikEtneWEu4iQgfKw-zkAT3Z=e7ohXgDq7oJAQvv@mail.gmail.com' \
--to=jaswinder.singh@linaro.org \
--cc=andy.green@linaro.org \
--cc=andy@warmcat.com \
--cc=benh@kernel.crashing.org \
--cc=broonie@opensource.wolfsonmicro.com \
--cc=grant.likely@secretlab.ca \
--cc=greg@kroah.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=nicolas.pitre@linaro.org \
--cc=roger.quadros@nokia.com \
/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).