From: Brian Norris <briannorris@chromium.org> To: Kalle Valo <kvalo@codeaurora.org> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>, govinds@codeaurora.org, linux-wireless@vger.kernel.org, Linux Kernel <linux-kernel@vger.kernel.org>, ath10k@lists.infradead.org Subject: Re: [PATCH] ath10k: retrieve MAC address from firmware if provided Date: Tue, 28 Aug 2018 17:14:54 -0700 [thread overview] Message-ID: <20180829001453.GA173345@ban.mtv.corp.google.com> (raw) In-Reply-To: <878t4qftnm.fsf@kamboji.qca.qualcomm.com> On Tue, Aug 28, 2018 at 05:33:01PM +0300, Kalle Valo wrote: > Arend van Spriel <arend.vanspriel@broadcom.com> writes: > > > On 8/13/2018 7:14 PM, Brian Norris wrote: > >> On Sat, Aug 11, 2018 at 11:26 AM Arend van Spriel > >> <arend.vanspriel@broadcom.com> wrote: > >>> > >>> On 8/11/2018 1:39 AM, Brian Norris wrote: > >>>> Devices may provide their own MAC address via system firmware (e.g., > >>> > >>> You got me confused by using just "firmware" in the subject. > >> > >> Yeah...I started by writing this patch with device tree specifically > >> (of_get_mac_address()), and then later found that there were generic > >> "device" helpers for this, which can assist with other sorts of > >> firmware nodes. It was easier to put a name on a device tree patch > >> than on a "device" patch. I suppose "system firmware" might be a > >> better description? > >> > >>>> device tree), especially in the case where the device doesn't have a > >>>> useful EEPROM on which to store its MAC address (e.g., for integrated > >>>> Wifi). > >>>> > >>>> Use the generic device helper to retrieve the MAC address, and (if > >>>> present) honor it above the MAC address advertised by the card. > >>> > >>> But this put me back on track ;-) > >> > >> Let me know if you have a better way to clarify. I can resend with a > >> slightly modified subject (s/firmware/system firmware/), or let Kalle > >> do it, if that's the only thing to change. > > > > "system firmware" substitution works for me. > > What about: > > ath10k: retrieve MAC address from Device Tree if provided > > Because from ath10k point of view we use Device Tree functions and don't > care if it's delivered by pidgeons or by system firmware :) I don't care too much, but note that Device Tree is a loaded term, usually referring specifically to a method of describing system hardware via the Flattened Device Tree format. If I were specifically targeting Device Tree, I'd use helpers like of_get_mac_address() instead. (The 'of_*' prefix is a relic of OpenFirmware, an early firmware implementation that used the Device Tree format.) If you're trying to say "device tree" to refer to "the Linux device hierarchy", then that's also a fair description. But that's all starting to mince words. Device Tree (with or without capitalization) is fine with me. Thanks, Brian > I can change this before I commit. > > -- > Kalle Valo
WARNING: multiple messages have this Message-ID (diff)
From: Brian Norris <briannorris@chromium.org> To: Kalle Valo <kvalo@codeaurora.org> Cc: Arend van Spriel <arend.vanspriel@broadcom.com>, govinds@codeaurora.org, linux-wireless@vger.kernel.org, Linux Kernel <linux-kernel@vger.kernel.org>, ath10k@lists.infradead.org Subject: Re: [PATCH] ath10k: retrieve MAC address from firmware if provided Date: Tue, 28 Aug 2018 17:14:54 -0700 [thread overview] Message-ID: <20180829001453.GA173345@ban.mtv.corp.google.com> (raw) In-Reply-To: <878t4qftnm.fsf@kamboji.qca.qualcomm.com> On Tue, Aug 28, 2018 at 05:33:01PM +0300, Kalle Valo wrote: > Arend van Spriel <arend.vanspriel@broadcom.com> writes: > > > On 8/13/2018 7:14 PM, Brian Norris wrote: > >> On Sat, Aug 11, 2018 at 11:26 AM Arend van Spriel > >> <arend.vanspriel@broadcom.com> wrote: > >>> > >>> On 8/11/2018 1:39 AM, Brian Norris wrote: > >>>> Devices may provide their own MAC address via system firmware (e.g., > >>> > >>> You got me confused by using just "firmware" in the subject. > >> > >> Yeah...I started by writing this patch with device tree specifically > >> (of_get_mac_address()), and then later found that there were generic > >> "device" helpers for this, which can assist with other sorts of > >> firmware nodes. It was easier to put a name on a device tree patch > >> than on a "device" patch. I suppose "system firmware" might be a > >> better description? > >> > >>>> device tree), especially in the case where the device doesn't have a > >>>> useful EEPROM on which to store its MAC address (e.g., for integrated > >>>> Wifi). > >>>> > >>>> Use the generic device helper to retrieve the MAC address, and (if > >>>> present) honor it above the MAC address advertised by the card. > >>> > >>> But this put me back on track ;-) > >> > >> Let me know if you have a better way to clarify. I can resend with a > >> slightly modified subject (s/firmware/system firmware/), or let Kalle > >> do it, if that's the only thing to change. > > > > "system firmware" substitution works for me. > > What about: > > ath10k: retrieve MAC address from Device Tree if provided > > Because from ath10k point of view we use Device Tree functions and don't > care if it's delivered by pidgeons or by system firmware :) I don't care too much, but note that Device Tree is a loaded term, usually referring specifically to a method of describing system hardware via the Flattened Device Tree format. If I were specifically targeting Device Tree, I'd use helpers like of_get_mac_address() instead. (The 'of_*' prefix is a relic of OpenFirmware, an early firmware implementation that used the Device Tree format.) If you're trying to say "device tree" to refer to "the Linux device hierarchy", then that's also a fair description. But that's all starting to mince words. Device Tree (with or without capitalization) is fine with me. Thanks, Brian > I can change this before I commit. > > -- > Kalle Valo _______________________________________________ ath10k mailing list ath10k@lists.infradead.org http://lists.infradead.org/mailman/listinfo/ath10k
next prev parent reply other threads:[~2018-08-29 4:09 UTC|newest] Thread overview: 16+ messages / expand[flat|nested] mbox.gz Atom feed top 2018-08-10 23:39 [PATCH] ath10k: retrieve MAC address from firmware if provided Brian Norris 2018-08-10 23:39 ` Brian Norris 2018-08-11 18:26 ` Arend van Spriel 2018-08-11 18:26 ` Arend van Spriel 2018-08-13 17:14 ` Brian Norris 2018-08-13 17:14 ` Brian Norris 2018-08-13 18:29 ` Arend van Spriel 2018-08-13 18:29 ` Arend van Spriel 2018-08-28 14:33 ` Kalle Valo 2018-08-28 14:33 ` Kalle Valo 2018-08-29 0:14 ` Brian Norris [this message] 2018-08-29 0:14 ` Brian Norris 2018-09-03 16:49 ` Kalle Valo 2018-09-03 16:49 ` Kalle Valo 2018-09-03 16:54 ` Kalle Valo 2018-09-03 16:54 ` Kalle Valo
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20180829001453.GA173345@ban.mtv.corp.google.com \ --to=briannorris@chromium.org \ --cc=arend.vanspriel@broadcom.com \ --cc=ath10k@lists.infradead.org \ --cc=govinds@codeaurora.org \ --cc=kvalo@codeaurora.org \ --cc=linux-kernel@vger.kernel.org \ --cc=linux-wireless@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.