From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753115AbcELTIg (ORCPT ); Thu, 12 May 2016 15:08:36 -0400 Received: from AUSXIPPC110.us.dell.com ([143.166.85.200]:6841 "EHLO ausxippc110.us.dell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753086AbcELTId (ORCPT ); Thu, 12 May 2016 15:08:33 -0400 DomainKey-Signature: s=smtpout; d=dell.com; c=nofws; q=dns; h=X-LoopCount0:X-IronPort-AV:From:To:CC:Subject: Thread-Topic:Thread-Index:Date:Message-ID:References: In-Reply-To:Accept-Language:Content-Language: X-MS-Has-Attach:X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader:x-originating-ip: Content-Type:Content-Transfer-Encoding:MIME-Version: Return-Path; b=fBB0kaZGsHJLV8Sz6nMvPd9/iw0zuEr16PbQnwcBgl9KBtqb+ibjgaCq MNgZ4nUtf1D28Udvhyh6W20H7QVMZRRYjSAv54OIEp0lmgF0SOwj98TE/ 8LMbfclqeG4DeRCA9dtH70+5wQpjOia1UbvkES+PHN7qlQdgYAGALrOdR Y=; X-LoopCount0: from 10.170.28.40 X-IronPort-AV: E=Sophos;i="5.24,610,1454997600"; d="scan'208";a="308648185" From: To: CC: , , , , Subject: RE: [PATCH v3 2/2] dell-laptop: Expose auxiliary MAC address if available Thread-Topic: [PATCH v3 2/2] dell-laptop: Expose auxiliary MAC address if available Thread-Index: AQHRqg9bjW4yknZIFkKuBAstxvtSJ5+0Eu2AgAA00gCAAAp7MIABAV2AgABbRlA= Date: Thu, 12 May 2016 19:08:30 +0000 Message-ID: References: <1462811099-16897-1-git-send-email-mario_limonciello@dell.com> <1462811099-16897-2-git-send-email-mario_limonciello@dell.com> <20160511133251.GA3440@eudyptula.hq.kempniu.pl> <201605111841.54411@pali> <3afbad44903b4da88b1362e938850da8@ausx13mpc120.AMER.DELL.COM> <20160512084033.GW29844@pali> In-Reply-To: <20160512084033.GW29844@pali> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.208.89.195] Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by mail.home.local id u4CJ8eHP032744 > -----Original Message----- > From: Pali Rohár [mailto:pali.rohar@gmail.com] > Sent: Thursday, May 12, 2016 3:41 AM > To: Limonciello, Mario > Cc: kernel@kempniu.pl; mjg59@srcf.ucam.org; dvhart@infradead.org; linux- > kernel@vger.kernel.org; platform-driver-x86@vger.kernel.org > Subject: Re: [PATCH v3 2/2] dell-laptop: Expose auxiliary MAC address if > available > > On Wednesday 11 May 2016 22:41:16 Mario_Limonciello@Dell.com wrote: > > > > > +static DEVICE_ATTR_RO(auxiliary_mac); static struct attribute > > > > > +*dell_attributes[] = { > > > > > + &dev_attr_auxiliary_mac.attr, > > > > > + NULL > > > > > +}; > > > > > + > > > > > +static const struct attribute_group dell_attr_group = { > > > > > + .attrs = dell_attributes, > > > > > +}; > > > > > + > > > > > > In my opinion this is not correct way to export "random" sysfs > > > attributes to userspace. If it is possible we should use existing > > > API/ABI for kernel and not to invent new ABI for userspace. > > > > > > Dell-laptop driver has already documented ABI for non standard > > > things (like extended settings for keyboard backlight), see: > > > https://www.kernel.org/doc/Documentation/ABI/testing/sysfs- > platform- > > > dell-laptop > > > > > > And exporting MAC address sounds for me like bad idea. I think it > > > should handle kernel itself (maybe send it to driver which use it?). > > > > > > And most important question: Who is going to use that sysfs file? Is > > > there any application? It is not possible to query for that address from > userspace, e.g. > > > from libsmbios tools? > > > > > > We have libsmbios functionality in kernel just for things which have > > > exiting API/ABI/interface in kernel. Not those which do not have... > > > > > > So why is needed to have such sysfs attribute exported by kernel? > > > > > > > I skipped your other comments because of this one. My original plan for > this was to do it in udev or Network Manager but you raise a good point. > > Maybe this patch should be scrapped all together. > > > > Mical - if you think patch 1/2 could still be useful to have as a general > interface I'll update it for your other comments and get it resubmitted. > > What is first patch doing? Can you send me link to it? > > > We do mirror the information in ACPI under the system bus: > > > > Scope (_SB) > > { > > Name (AMAC, Buffer (0x17) > > { > > "_AUXMAC_#847BEB5992D2#" > > }) > > } > > > > I don't know how to properly access this from the kernel side. I noticed > that most drivers that reference ACPI nodes refer to devices, not something > hanging off the system bus. > > If you could advise the right way to go about that, I would appreciate it. > > So there are two ways how to read that MAC address. One is via SMM and > one via ACPI. Yes, this isn't a general statement for read only static information, but in this case it is true. > You can also read ACPI buffer (name is probably \_SB.AMAC) with ACPI > functions in kernel. Ask ACPI people, for correct API. I'm sure this is possible > also without creating new ACPI driver... Thanks will do. > > > If I can access that, maybe it's better to do this directly as a patch to the > Ethernet driver in question (r8152). > > That's actually how it's handled on the OS side for Windows too from what I > understand. > > We have some FW bit set in them to indicate they're Dell Realtek products > (don't have this detail yet). > > When they see that bit they look for that ACPI buffer and use it to set the > MAC address the OS sees. > > Maybe it should be better to chose same way as Windows drivers? Better > ask on netdev mailing list and ping maintainers of that ethernet driver what > they think about it. > > For me it sounds like a better solution (patching that ethernet driver) as > exporting some non-standard sysfs node from kernel with MAC address and > then using another tool which send that MAC address back to kernel. > Great, thank you for your feedback. I'll wander down that rabbit hole.