From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arnd Bergmann Subject: Re: [PATCH 2/3] OMAP2+ devices add mac address allocation register api Date: Mon, 2 Jul 2012 07:15:45 +0000 Message-ID: <201207020715.46084.arnd@arndb.de> References: <20120629054404.11091.31289.stgit@build.warmcat.com> <201206291505.07249.arnd@arndb.de> <20120701085841.GL4202@atomide.com> Mime-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Return-path: Received: from moutng.kundenserver.de ([212.227.126.186]:59968 "EHLO moutng.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932938Ab2GBKUV (ORCPT ); Mon, 2 Jul 2012 06:20:21 -0400 In-Reply-To: <20120701085841.GL4202@atomide.com> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Tony Lindgren Cc: Andy Green , linux-omap@vger.kernel.org, linux-arm-kernel@lists.infradead.org, nicolas.pitre@linaro.org, s-jan@ti.com, patches@linaro.org, rostedt@goodmis.org On Sunday 01 July 2012, Tony Lindgren wrote: > > > 2. Pass the Panda mac information as platform data to this > > > driver for now with a comment on the usb path naming being > > > potentially wrong in the loadable modules case. > > > > IMHO code outside of the platform driver world would be more > > appropriate here. It's not actually a platform device because > > it's more of an abstract concept to define a mac address than > > physical hardware. > > Well we still need to also pass the mac address generated by > the SoC specific kernel init code. It seems that platform data > would be the obvious way to pass that. Or do you have some other > way in mind for that? My point is that for platform data you need a platform device of some sort, but this new piece of infrastructure does not look like it should be a device. I think a reasonable interface would be something as simple as void register_eth_mac_fixup(const char *path, const u8 *mac); Instead of registering a device from the platform, we just call this function, and leave the code built-in. Arnd From mboxrd@z Thu Jan 1 00:00:00 1970 From: arnd@arndb.de (Arnd Bergmann) Date: Mon, 2 Jul 2012 07:15:45 +0000 Subject: [PATCH 2/3] OMAP2+ devices add mac address allocation register api In-Reply-To: <20120701085841.GL4202@atomide.com> References: <20120629054404.11091.31289.stgit@build.warmcat.com> <201206291505.07249.arnd@arndb.de> <20120701085841.GL4202@atomide.com> Message-ID: <201207020715.46084.arnd@arndb.de> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On Sunday 01 July 2012, Tony Lindgren wrote: > > > 2. Pass the Panda mac information as platform data to this > > > driver for now with a comment on the usb path naming being > > > potentially wrong in the loadable modules case. > > > > IMHO code outside of the platform driver world would be more > > appropriate here. It's not actually a platform device because > > it's more of an abstract concept to define a mac address than > > physical hardware. > > Well we still need to also pass the mac address generated by > the SoC specific kernel init code. It seems that platform data > would be the obvious way to pass that. Or do you have some other > way in mind for that? My point is that for platform data you need a platform device of some sort, but this new piece of infrastructure does not look like it should be a device. I think a reasonable interface would be something as simple as void register_eth_mac_fixup(const char *path, const u8 *mac); Instead of registering a device from the platform, we just call this function, and leave the code built-in. Arnd