| lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
|
Open Source and information security mailing list archives
| ||
|
Date: Mon, 19 Mar 2012 07:54:33 +0100 From: Lothar Waßmann <LW@...O-electronics.de> To: Grant Likely <grant.likely@...retlab.ca> Cc: Dong Aisheng <aisheng.dong@...escale.com>, Dong Aisheng-B29396 <B29396@...escale.com>, "s.hauer\@pengutronix.de" <s.hauer@...gutronix.de>, Guo Shawn-R65073 <r65073@...escale.com>, "vinod.koul\@linux.intel.com" <vinod.koul@...ux.intel.com>, "devicetree-discuss\@lists.ozlabs.org" <devicetree-discuss@...ts.ozlabs.org>, "linux-mmc\@vger.kernel.org" <linux-mmc@...r.kernel.org>, "linux-kernel\@vger.kernel.org" <linux-kernel@...r.kernel.org>, "rob.herring\@calxeda.com" <rob.herring@...xeda.com>, "rdunlap\@xenotime.net" <rdunlap@...otime.net>, "kernel\@pengutronix.de" <kernel@...gutronix.de>, "cjb\@laptop.org" <cjb@...top.org>, "linux-arm-kernel\@lists.infradead.org" <linux-arm-kernel@...ts.infradead.org> Subject: Re: [PATCH v1 1/5] ARM: imx28: add basic dt support Hi, Grant Likely writes: > On Fri, 16 Mar 2012 11:01:35 +0800, Dong Aisheng <aisheng.dong@...escale.com> wrote: > > On Thu, Mar 15, 2012 at 07:22:04PM +0800, Lothar Waßmann wrote: > > > Hi, > > > > > > Dong Aisheng writes: > > > > On Thu, Mar 15, 2012 at 02:53:29PM +0800, Lothar Waßmann wrote: > > > > > Hi, > > > > > > > > > > Dong Aisheng writes: > > > > > > On Wed, Mar 14, 2012 at 10:16:43PM +0800, s.hauer@...gutronix.de wrote: > > > > > > > On Wed, Mar 14, 2012 at 08:45:23PM +0800, Dong Aisheng wrote: > > > > > > > > On Wed, Mar 14, 2012 at 01:23:51AM +0800, Grant Likely wrote: > > > > > [...] > > > > > > > > But it seems this needs pass mac address to fec driver via platforom data which is > > > > > > > > not friendly to dt. > > > > > > > > > > > > > > > > Another way may be changing fec driver to get the fixed part of mac address(first > > > > > > > > two bytes) from device tree and read the left dynamical part from otp which i'm not > > > > > > > > sure is better enough. > > > > > > > > > > > > > > > > BTW, filling with zeros seems not work since it's invalid mac address. > > > > > > > > > > > > > > Yes, that's the idea of using this value... > > > > > > > > > > > > > But comparing to use an invalid value, why not just do not define that > > > > > > local-mac-address property? > > > > > > > > > > > Because a MAC address is by definition a GLOBALLY UNIQUE IDENTIFIER > > > > > which is contrary to coding a "valid" default value for it somewhere! > > > > > The owner of a certain MAC address range (OUI) is responsible for > > > > > ensuring the uniqueness. Thus only they may assign a specific MAC > > > > > address to a specific device. > > > > > > > > > Yes, you're correct. > > > > So i propose to read the MAC address from MX28 OTP in fec driver instead of > > > > define it in device tree in my last mail. > > > > http://www.spinics.net/lists/arm-kernel/msg165040.html > > > > Do you have any comment on that way? > > > > > > > That patch sets the OUI to the Freescale owned MAC range. Thus only > > > Freescale products may be able to use the driver. > > > > > No. > > My proposal is only set the fixed part(first two octets) in board dts file, > > each board knows it's value, and read the left 4 octets from OCOTP dynamically. > > Obviously the freeescale board dts file is only for FSL platforms. > > Other platforms can define their fix part of MAC address in their dts file. > > > > > Anyway there is no definite spec how the MAC address(es) are stored > > > in the fuse map. Thus reading the MAC from there is more or less > > > platform specific. > > > > > It's just provide one more option since there are customers storing the MAC > > in the fuse map. > > That should be straight forward to support; have a property that > specifies the method used for fetching/calculating the MAC. > Executable code stored inside a DT blob? ;) > > > Currently I'm setting up the MAC address for our TX28 from the fuses > > > in the platform code passed via platform_data, but that will obviously > > > not work with DT. > > > > > Non-dt can also use my proposal, then you only need to pass the fixed part of > > MAC via platfrom data, the left will be read by fec driver. > > > > > The correct way would probably be to pass the MAC from the bootloader > > > via a DT blob. But that would require all bootloaders to be updated > > > first to support DTS. :( > > > > > But uboot will face the same problem that can not define a valid MAC > > in dts, did i undertand correctly? > > > > > An intermediate solution could be using OF_DEV_AUXDATA to pass a > > > platform_data struct that may contain a MAC address set up by the > > > platform code. > > > > > Yes, it's a way but i'm afraid will not get accepted by dt people. > > The problem remains; where does the platform code get the MAC address > from? The kernel has to devise it from *somewhere* and the best place > for that should be in the MAC driver itself. > The platform code knows how and where the MAC is stored on a specific platform. The driver has no business in knowing platform details like this. Thus only platform code (or the bootloader) can provide the MAC to the driver. > I've got no problem with the idea of only specifying the OUI in the DT > and the driver extracting the remaining 3 bytes from the hardware. > > In principle, that's the design intent for DT systems anyway; it > describes things which cannot be probed from the hardware, or tells > the OS how the data is encoded in the hardware. > If all bootloaders were aware of DT this wouldn't be a problem, because they could place the correct MAC inside the DT blob right away. But in the mean time (AKA forever) we need some other solution. Lothar Waßmann -- ___________________________________________________________ Ka-Ro electronics GmbH | Pascalstraße 22 | D - 52076 Aachen Phone: +49 2408 1402-0 | Fax: +49 2408 1402-10 Geschäftsführer: Matthias Kaussen Handelsregistereintrag: Amtsgericht Aachen, HRB 4996 www.karo-electronics.de | info@...o-electronics.de ___________________________________________________________ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists