From: Arend van Spriel <arend.vanspriel@broadcom.com>
To: Kalle Valo <kvalo@codeaurora.org>, Bas Vermeulen <bvermeul@blackstar.nl>
Cc: linux-wireless@vger.kernel.org, ath9k-devel@qca.qualcomm.com,
Felix Fietkau <nbd@nbd.name>,
Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Subject: Re: [PATCH] ath9k: introduce endian_check module parameter
Date: Wed, 14 Mar 2018 22:34:17 +0100 [thread overview]
Message-ID: <5AA99559.2070605@broadcom.com> (raw)
In-Reply-To: <874lli7mk5.fsf@codeaurora.org>
+ Martin
On 3/14/2018 3:34 PM, Kalle Valo wrote:
> Bas Vermeulen <bvermeul@blackstar.nl> writes:
>
>>>>>> --- a/drivers/net/wireless/ath/ath9k/init.c
>>>>>> +++ b/drivers/net/wireless/ath/ath9k/init.c
>>>>>> @@ -67,6 +67,9 @@ static int ath9k_ps_enable;
>>>>>> module_param_named(ps_enable, ath9k_ps_enable, int, 0444);
>>>>>> MODULE_PARM_DESC(ps_enable, "Enable WLAN PowerSave");
>>>>>> +static int ath9k_endian_check;
>>>>>> +module_param_named(endian_check, ath9k_endian_check, int, 0444);
>>>>>> +MODULE_PARM_DESC(endian_check, "Check EEPROM for endianness compatibility");
>>>>>> #ifdef CONFIG_ATH9K_CHANNEL_CONTEXT
>>>>>> int ath9k_use_chanctx;
>>>>>> @@ -587,7 +590,8 @@ static int ath9k_of_init(struct ath_softc *sc)
>>>>>> ether_addr_copy(common->macaddr, mac);
>>>>>> ah->ah_flags &= ~AH_USE_EEPROM;
>>>>>> - ah->ah_flags |= AH_NO_EEP_SWAP;
>>>>>> + if (!ath9k_endian_check)
>>>>>> + ah->ah_flags |= AH_NO_EEP_SWAP;
>>>>> A bit annoying to have a module parameter, isn't there any automatic way
>>>>> to detect/try this? But on the other hand I guess this isn't a common
>>>>> problem as nobody has reported this before?
>>>>
>>>> There is an automatic way to detect this, but that is disabled by the
>>>> AH_NO_EEP_SWAP flag.
>>>
>>> Ah, I didn't check the code at all.
>>>
>>>> The platform initialisation does not set this flag if the endian_check
>>>> member of pdata is set to true, but there is no way to not set this
>>>> when using a device tree. I used a module parameter instead of a
>>>> device tree variable because I don't know of a way to modify the
>>>> device tree my PowerMac boots with.
>>>
>>> Ok, makes sense. A module parameter is not an ideal solution I guess
>>> it's ok in this case.
>>>
>> Kalle: Are there any changes you want me to make in order to get this
>> accepted? I didn't see anything for me to resolve, but I may have
>> missed something.
>>
>> I can submit a patch to not set the AH_NO_EEP_SWAP flag by default if
>> you prefer, as that would fix my problem as well. I am just not sure
>> that doesn't break things for some platform/device I don't have.
>
> I'm not really sure what to do. Basically this is a choise between bad
> for user experience (the module parameter) or risk of regressions
> (disable AH_NO_EEP_SWAP by default). As ath9k is used in very exotic
> hardware I'm starting to lean towards the module parameter approach
> (your patch) but would like to know what others think, especially Felix
> (CCed).
Hi Kalle,
Sorry for barging in, but I figured git history might tell us something.
The flag was originally added by Felix (commit a59dadbeeaf7 ("ath9k: add
support for endian swap of eeprom from platform data")) and the function
ath9k_of_init() was added by Martin (CCed):
commit 138b41253d9c9f9a06c8b086880cd3e839a23d69
Author: Martin Blumenstingl <martin.blumenstingl@googlemail.com>
Date: Sun Oct 16 22:59:07 2016 +0200
ath9k: parse the device configuration from an OF node
Maybe he recalls what device(s) needed it.
Regards,
Arend
next prev parent reply other threads:[~2018-03-14 21:34 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-02-26 9:09 [PATCH] ath9k: introduce endian_check module parameter Bas Vermeulen
2018-02-26 9:54 ` Kalle Valo
2018-02-26 10:07 ` Bas Vermeulen
2018-02-26 11:30 ` Sebastian Gottschall
2018-02-26 12:26 ` Bas Vermeulen
2018-02-26 14:52 ` Kalle Valo
2018-03-14 12:42 ` Bas Vermeulen
2018-03-14 14:34 ` Kalle Valo
2018-03-14 21:34 ` Arend van Spriel [this message]
2018-03-19 8:11 ` Martin Blumenstingl
2018-03-20 21:07 ` Rafał Miłecki
2018-03-20 21:14 ` Martin Blumenstingl
2018-03-24 8:05 ` Mathias Kresin
2018-04-10 9:05 ` Bas Vermeulen
2018-04-12 18:53 ` Martin Blumenstingl
2018-02-26 16:32 ` Larry Finger
2018-02-26 16:44 ` Bas Vermeulen
2018-02-26 17:42 ` Dan Williams
2018-02-26 21:42 ` Bas Vermeulen
2018-02-26 11:28 ` Sebastian Gottschall
2018-02-26 12:21 ` Bas Vermeulen
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=5AA99559.2070605@broadcom.com \
--to=arend.vanspriel@broadcom.com \
--cc=ath9k-devel@qca.qualcomm.com \
--cc=bvermeul@blackstar.nl \
--cc=kvalo@codeaurora.org \
--cc=linux-wireless@vger.kernel.org \
--cc=martin.blumenstingl@googlemail.com \
--cc=nbd@nbd.name \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).