From: Greg KH <greg@kroah.com>
To: Andy Green <andy@warmcat.com>
Cc: linux-kernel@vger.kernel.org, linux-usb@vger.kernel.org,
linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org,
patches@linaro.org, Andy Green <andy.green@linaro.org>
Subject: Re: [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition
Date: Sat, 12 Mar 2011 17:05:10 -0800 [thread overview]
Message-ID: <20110313010510.GC20396@kroah.com> (raw)
In-Reply-To: <20110312225039.27728.24017.stgit@otae.warmcat.com>
On Sat, Mar 12, 2011 at 10:50:39PM +0000, Andy Green wrote:
> This is part of an RFC patch series introducing asynchronous platform
> data, which may be attached to discovered bus devices at probe time
> based on the device path.
>
> As part of the series, platform_data is enabled in usbnet layer.
>
> This patch defines the usbnet platform data, allowing the panda board
> definition file to assert the naming of the usbnet network interface
> should be eth%d instead of usb%d.
Why is this? If you want to do this, it should be done in userspace
today, no need to involve the kernel in this type of thing.
So I don't see the point of this patch.
thanks,
greg k-h
WARNING: multiple messages have this Message-ID (diff)
From: greg@kroah.com (Greg KH)
To: linux-arm-kernel@lists.infradead.org
Subject: [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition
Date: Sat, 12 Mar 2011 17:05:10 -0800 [thread overview]
Message-ID: <20110313010510.GC20396@kroah.com> (raw)
In-Reply-To: <20110312225039.27728.24017.stgit@otae.warmcat.com>
On Sat, Mar 12, 2011 at 10:50:39PM +0000, Andy Green wrote:
> This is part of an RFC patch series introducing asynchronous platform
> data, which may be attached to discovered bus devices at probe time
> based on the device path.
>
> As part of the series, platform_data is enabled in usbnet layer.
>
> This patch defines the usbnet platform data, allowing the panda board
> definition file to assert the naming of the usbnet network interface
> should be eth%d instead of usb%d.
Why is this? If you want to do this, it should be done in userspace
today, no need to involve the kernel in this type of thing.
So I don't see the point of this patch.
thanks,
greg k-h
next prev parent reply other threads:[~2011-03-13 1:06 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-12 22:50 [RFC PATCH 0/5] OMAP2+ / Panda implementation for async platform_data Andy Green
2011-03-12 22:50 ` Andy Green
2011-03-12 22:50 ` [RFC PATCH 1/5] OMAP2+: Panda introduce async platform data definition Andy Green
2011-03-12 22:50 ` Andy Green
2011-03-13 1:05 ` Greg KH [this message]
2011-03-13 1:05 ` Greg KH
2011-03-12 22:50 ` [RFC PATCH 2/5] OMAP2+: add cpu id register to MAC address helper Andy Green
2011-03-12 22:50 ` Andy Green
2011-03-18 8:34 ` Arnd Bergmann
2011-03-18 8:34 ` Arnd Bergmann
2011-03-18 8:49 ` Andy Green
2011-03-18 8:49 ` Andy Green
2011-03-18 14:37 ` Premi, Sanjeev
2011-03-18 14:37 ` Premi, Sanjeev
[not found] ` <B85A65D85D7EB246BE421B3FB0FBB593024C3B8670-/tLxBxkBPtCIQmiDNMet8wC/G2K4zDHf@public.gmane.org>
2011-03-18 14:47 ` Andy Green
2011-03-18 14:47 ` Andy Green
2011-03-18 14:47 ` Andy Green
[not found] ` <20110312225047.27728.1835.stgit-MbR9/eEqKADKkTgpAXvmkg@public.gmane.org>
2011-03-18 8:52 ` Roger Quadros
2011-03-18 8:52 ` Roger Quadros
2011-03-18 8:52 ` Roger Quadros
[not found] ` <4D831D4B.8090407-xNZwKgViW5gAvxtiuMwx3w@public.gmane.org>
2011-03-18 9:13 ` Andy Green
2011-03-18 9:13 ` Andy Green
2011-03-18 9:13 ` Andy Green
2011-03-12 22:50 ` [RFC PATCH 3/5] OMAP2+:Common CPU DIE ID reading code reads wrong registers for OMAP4430 Andy Green
2011-03-12 22:50 ` Andy Green
2011-03-14 18:12 ` Tony Lindgren
2011-03-14 18:12 ` Tony Lindgren
2011-03-12 22:51 ` [RFC PATCH 4/5] OMAP2+: Set onboard Ethernet MAC address using unique CPU ID data Andy Green
2011-03-12 22:51 ` Andy Green
[not found] ` <20110312224440.27728.60593.stgit-MbR9/eEqKADKkTgpAXvmkg@public.gmane.org>
2011-03-12 22:51 ` [RFC PATCH 5/5] USBNET: SMSC95XX: if mac set in platform data no need for random one Andy Green
2011-03-12 22:51 ` Andy Green
2011-03-12 22:51 ` Andy Green
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=20110313010510.GC20396@kroah.com \
--to=greg@kroah.com \
--cc=andy.green@linaro.org \
--cc=andy@warmcat.com \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-omap@vger.kernel.org \
--cc=linux-usb@vger.kernel.org \
--cc=patches@linaro.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.