From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tony Lindgren Subject: Re: [PATCH 2/3] OMAP2+ devices add mac address allocation register api Date: Mon, 2 Jul 2012 03:51:03 -0700 Message-ID: <20120702105102.GG1122@atomide.com> References: <20120629054404.11091.31289.stgit@build.warmcat.com> <201206291505.07249.arnd@arndb.de> <20120701085841.GL4202@atomide.com> <201207020715.46084.arnd@arndb.de> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from mho-02-ewr.mailhop.org ([204.13.248.72]:42130 "EHLO mho-02-ewr.mailhop.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S932931Ab2GBKvH (ORCPT ); Mon, 2 Jul 2012 06:51:07 -0400 Content-Disposition: inline In-Reply-To: <201207020715.46084.arnd@arndb.de> Sender: linux-omap-owner@vger.kernel.org List-Id: linux-omap@vger.kernel.org To: Arnd Bergmann 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 * Arnd Bergmann [120702 03:24]: > 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. OK > 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. Sounds good to me. Tony From mboxrd@z Thu Jan 1 00:00:00 1970 From: tony@atomide.com (Tony Lindgren) Date: Mon, 2 Jul 2012 03:51:03 -0700 Subject: [PATCH 2/3] OMAP2+ devices add mac address allocation register api In-Reply-To: <201207020715.46084.arnd@arndb.de> References: <20120629054404.11091.31289.stgit@build.warmcat.com> <201206291505.07249.arnd@arndb.de> <20120701085841.GL4202@atomide.com> <201207020715.46084.arnd@arndb.de> Message-ID: <20120702105102.GG1122@atomide.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org * Arnd Bergmann [120702 03:24]: > 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. OK > 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. Sounds good to me. Tony