From: Hans de Goede <hdegoede@xxxxxxxxxx> Date: Sat, 16 Jul 2016 12:12:37 +0200 > Hi, > > On 15-07-16 19:51, David Miller wrote: >> From: Hans de Goede <hdegoede@xxxxxxxxxx> >> Date: Fri, 15 Jul 2016 08:40:00 +0200 >> >>> Hi, >>> >>> On 15-07-16 01:17, David Miller wrote: >>>> From: Hans de Goede <hdegoede@xxxxxxxxxx> >>>> Date: Wed, 13 Jul 2016 12:20:04 +0200 >>>> >>>>> On some boards (android tablets) different batches use different sdio >>>>> wifi modules. This is not a problem since sdio is a discoverable bus, >>>>> so we only need to describe and activate the mmc controller in dt and >>>>> then the kernel will automatically load the right driver. >>>>> >>>>> But sometimes it is useful to specify certain ethernet properties for >>>>> these "unknown" sdio devices, specifically we want the boot-loader >>>>> to be able to set "local-mac-address" as some of these sdio wifi >>>>> modules come without an eeprom / without a factory programmed mac >>>>> address. >>>>> >>>>> Since the exact device is unknown (differs per batch) we cannot use >>>>> a wifi-chip specific compatible. This commit adds a new >>>>> "generic,ethernet" binding for use in dt-nodes describing such an >>>>> unknown ethernet device. >>>>> >>>>> Cc: Maxime Ripard <maxime.ripard@xxxxxxxxxxxxxxxxxx> >>>>> Signed-off-by: Hans de Goede <hdegoede@xxxxxxxxxx> >>>> >>>> Precedence exists for a "system ethernet address" as far back as the >>>> original sparc device tree implementation, so please just specify it >>>> that way rather than trying to force having to make an alias or >>>> reference to it from a specific device. >>> >>> Some boards where this is applicable have both a wired and a wireless >>> ethernet, so one global setting will not work. >> >> Then call it "eth:local-mac-address" and "wifi:local-mac-address" > > Until we get a board with 2 ethernet interfaces, really the alias > thing > is working fine here, that is not the problem. Fair enough. -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html