From: Kalle Valo <kvalo@codeaurora.org>
To: "Daniel F. Dickinson" <cshored@thecshore.com>
Cc: ath9k-devel@qca.qualcomm.com, linux-wireless@vger.kernel.org,
chunkeey@gmail.com, "Daniel F. Dickinson" <cshored@thecshore.com>
Subject: Re: [PATCH] ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom
Date: Thu, 10 Jan 2019 13:29:05 +0000 (UTC) [thread overview]
Message-ID: <20190110132905.A8367607F4@smtp.codeaurora.org> (raw)
In-Reply-To: <20181222060913.28434-1-cshored@thecshore.com>
"Daniel F. Dickinson" <cshored@thecshore.com> wrote:
> ath9k_of_init() function[0] was initially written on the assumption that
> if someone had an explicit ath9k OF node that "there must be something
> wrong, why would someone add an OF node if everything is fine"[1]
> (Quoting Martin Blumenstingl <martin.blumenstingl@googlemail.com>)
>
> "it turns out it's not that simple. with your requirements I'm now aware
> of two use-cases where the current code in ath9k_of_init() doesn't work
> without modifications"[1]
>
> The "your requirements" Martin speaks of is the result of the fact that I
> have a device (PowerCloud Systems CR5000) has some kind of default - not
> unique mac address - set and requires to set the correct MAC address via
> mac-address devicetree property, however:
>
> "some cards come with a physical EEPROM chip [or OTP] so "qca,no-eeprom"
> should not be set (your use-case). in this case AH_USE_EEPROM should be
> set (which is the default when there is no OF node)"[1]
>
> The other use case is:
>
> the firmware on some PowerMac G5 seems to add a OF node for the ath9k
> card automatically. depending on the EEPROM on the card AH_NO_EEP_SWAP
> should be unset (which is the default when there is no OF node). see [3]
>
> After this patch to ath9k_of_init() the new behavior will be:
>
> if there's no OF node then everything is the same as before
> if there's an empty OF node then ath9k will use the hardware EEPROM
> (before ath9k would fail to initialize because no EEPROM data was
> provided by userspace)
> if there's an OF node with only a MAC address then ath9k will use
> the MAC address and the hardware EEPROM (see the case above)
> with "qca,no-eeprom" EEPROM data from userspace will be requested.
> the behavior here will not change
> [1]
>
> Martin provides additional background on EEPROM swapping[1].
>
> Thanks to Christian Lamparter <chunkeey@gmail.com> for all his help on
> troubleshooting this issue and the basis for this patch.
>
> [0]https://elixir.bootlin.com/linux/v4.20-rc7/source/drivers/net/wireless/ath/ath9k/init.c#L615
> [1]https://github.com/openwrt/openwrt/pull/1645#issuecomment-448027058
> [2]https://github.com/openwrt/openwrt/pull/1613
> [3]https://patchwork.kernel.org/patch/10241731/
>
> Fixes: 138b41253d9c ("ath9k: parse the device configuration from an OF node")
> Reviewed-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Tested-by: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
> Signed-off-by: Daniel F. Dickinson <cshored@thecshore.com>
> Signed-off-by: Kalle Valo <kvalo@codeaurora.org>
Patch applied to ath-next branch of ath.git, thanks.
ce938231bd3b ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom
--
https://patchwork.kernel.org/patch/10741449/
https://wireless.wiki.kernel.org/en/developers/documentation/submittingpatches
prev parent reply other threads:[~2019-01-10 13:29 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-22 6:09 [PATCH] ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom Daniel F. Dickinson
2018-12-22 11:08 ` Martin Blumenstingl
2018-12-23 0:42 ` Out of order Re: to PATCH confused Patchwork (was Re: [PATCH] ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom) Daniel F. Dickinson
2019-01-07 13:23 ` [PATCH] ath9k: Avoid OF no-EEPROM quirks without qca,no-eeprom Kalle Valo
2019-01-10 13:29 ` Kalle Valo [this message]
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=20190110132905.A8367607F4@smtp.codeaurora.org \
--to=kvalo@codeaurora.org \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=chunkeey@gmail.com \
--cc=cshored@thecshore.com \
--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: link
Be 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.