Re: [1/2] ath10k: Replace warning with an error message if HTT op version is unset
Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Print an ath10k error message rather a call trace when HTT op version is > not found from firmware META data (IE). This should be sufficient to figure > out what went wrong. > > Signed-off-by: Mohammed Shafi Shajakhan Thanks, 1 patch applied to ath-next branch of ath.git: ce30c4fe1a22 ath10k: replace warning with an error message if HTT op version is unset -- Sent by pwcli https://patchwork.kernel.org/patch/9195581/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] ath10k: remove unused member in ath10k_hw_regs
ako...@qti.qualcomm.com wrote: > From: Anilkumar Kolli > > rtc_state_cold_reset_mask is unused in ath10k_hw_regs. > instead fixed delays are used. > > Signed-off-by: Anilkumar Kolli Thanks, 2 patches applied to ath-next branch of ath.git: 2225378d840c ath10k: remove unused member in ath10k_hw_regs e565c3125e03 ath10k: enable support for QCA9888 -- Sent by pwcli https://patchwork.kernel.org/patch/9189535/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2,3/5] ath10k: Add WARN_ON if we over-write peer-map pointer.
Ben Greear wrote: > From: Ben Greear > > Not sure this can happen, but seems like a reasonable sanity > check. > > Signed-off-by: Ben Greear Thanks, 2 patches applied to ath-next branch of ath.git: c5ace87a886d ath10k: Add WARN_ON if we over-write peer-map pointer. d0eeafad1189 ath10k: Clean up peer when sta goes away. -- Sent by pwcli https://patchwork.kernel.org/patch/8727861/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath10k: remove extra space on ath10k_update_channel_list
Eduardo Abinader wrote: > just to comply to coding style. > > Signed-off-by: Eduardo Abinader > Reviewed-by: Julian Calaby Thanks, 1 patch applied to ath-next branch of ath.git: 9802977dcce5 ath10k: remove extra space on ath10k_update_channel_list -- Sent by pwcli https://patchwork.kernel.org/patch/9192945/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath10k: simplify pktlog htt event processing
Ashok Raj Nagarajan wrote: > It is expected that all pktlog events for 10.4 firmware based solutions > should come through CE8 where as in case of 10.2 firmware based solutions, > it should come through one of the HTT events (HTT_T2H_MSG_TYPE_PKTLOG). > > But from experiments with 10.4 based solutions, it is observed that pktlog > event for ATH_PKTLOG_TYPE_TX_MSDU_ID is coming through HTT pktlog event. > Currently, we always parse with 10.2 pktlog header which will lead to > pktlog decoding issues (payload length mismatch exceptions) > > For trace points, it is required to provide only the payload size. So > fixing this by simplifying the payload size calculation without the use of > ath10k pktlog headers. > > While there, remove the unused ath10k pktlog headers. > > Signed-off-by: Ashok Raj Nagarajan Thanks, 1 patch applied to ath-next branch of ath.git: 34293f75586b ath10k: simplify pktlog htt event processing -- Sent by pwcli https://patchwork.kernel.org/patch/9192399/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [1/2] ath10k: remove unused
Chaehyun Lim wrote: > is not used anymore, so just remove it. > > Signed-off-by: Chaehyun Lim Thanks, 1 patch applied to ath-next branch of ath.git: a3dadad73324 ath10k: remove unused -- Sent by pwcli https://patchwork.kernel.org/patch/9190357/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v2, 1/5] ath10k: Ensure txrx-compl-task is stopped when cleaning htt-tx.
Ben Greear wrote: > From: Ben Greear > > Otherwise, the txrx-compl-task may access some bad memory? > > Signed-off-by: Ben Greear Thanks, 2 patches applied to ath-next branch of ath.git: de0170beaa88 ath10k: ensure txrx-compl-task is stopped when cleaning htt-tx 6d68f7900d25 ath10k: ensure peer_map references are cleaned up -- Sent by pwcli https://patchwork.kernel.org/patch/8727831/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v4,1/2] ath10k: Add support for ath10k_sta_statistics support
Mohammed Shafi Shajakhan wrote: > From: Mohammed Shafi Shajakhan > > Enable support for 'drv_sta_statistics' callback. > Export rx_duration support if available to cfg80211/nl80211 > > This can also act as a placeholder for any new per STA stats support > > Signed-off-by: Mohammed Shafi Shajakhan Thanks, 2 patches applied to ath-next branch of ath.git: 120a1f02a5c4 ath10k: add support for ath10k_sta_statistics support 2ba1f3709452 ath10k: remove debugfs support for Per STA total rx duration -- Sent by pwcli https://patchwork.kernel.org/patch/9175135/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [v3] ath10k: Fix 10.4 extended peer stats update
Mohammed Shafi Shajakhan wrote:
> From: Mohammed Shafi Shajakhan
>
> 10.4 'extended peer stats' will be not be appended with normal peer stats
> data and they shall be coming in separate chunks. Fix this by maintaining
> a separate linked list 'extender peer stats' for 10.4 and update
> rx_duration for per station statistics. Also parse through beacon filter
> (if enabled), to make sure we parse the extended peer stats properly.
> This issue was exposed when more than one client is connected and
> extended peer stats for 10.4 is enabled
>
> The order for the stats is as below
> S - standard peer stats, E- extended peer stats, B - beacon filter stats
>
> {S1, S2, S3..} -> {B1, B2, B3..}(if available) -> {E1, E2, E3..}
>
> Fixes: f9575793d44c ("ath10k: enable parsing per station rx duration for
> 10.4")
> Signed-off-by: Mohammed Shafi Shajakhan
Thanks, 1 patch applied to ath-next branch of ath.git:
4a49ae94a448 ath10k: fix 10.4 extended peer stats update
--
Sent by pwcli
https://patchwork.kernel.org/patch/9149357/
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()
On Fri, 2016-07-08 at 12:15 +0900, Masashi Honma wrote: = > Thanks for comment. > > I have selected GFP flags based on existing code. > > I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because > skb was allocated with GFP_ATOMIC. Point is : we should remove GFP_ATOMIC uses as much as we can. Everytime we see one of them, we should think why it was added and if this is really needed. inet6_netconf_get_devconf() is a perfect example of one careless GFP_ATOMIC usage https://patchwork.ozlabs.org/patch/646291/ -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()
On 2016年07月08日 11:56, Eric Dumazet wrote: Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in this patch is definitely not good. Further more, RTNL is a mutex, held in control path, designed to allow schedules and waiting for memory under pressure. We do not want to encourage GFP_ATOMIC usage in control path. Your patch series gives the wrong signal to developers. Thanks for comment. I have selected GFP flags based on existing code. I have selected GFP_ATOMIC in inet6_netconf_get_devconf() because skb was allocated with GFP_ATOMIC. I have used GFP_KERNEL in inet6_rtm_getaddr() by same reason. > I will send a patch against net/ipv4/devinet.c so that we remove > GFP_ATOMIC usage there. Thanks. I will modify my patch based on your new code. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC 5/7] net: Add allocation flag to rtnl_unicast()
On Wed, 2016-07-06 at 09:28 +0900, Masashi Honma wrote: > Signed-off-by: Masashi Honma > --- > diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c > index a1f6b7b..2b0b994 100644 > --- a/net/ipv6/addrconf.c > +++ b/net/ipv6/addrconf.c > @@ -628,7 +628,7 @@ static int inet6_netconf_get_devconf(struct sk_buff > *in_skb, > kfree_skb(skb); > goto errout; > } > - err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid); > + err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid, GFP_ATOMIC); > errout: > return err; > } > @@ -4824,7 +4824,7 @@ static int inet6_rtm_getaddr(struct sk_buff *in_skb, > struct nlmsghdr *nlh) > kfree_skb(skb); > goto errout_ifa; > } > - err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid); > + err = rtnl_unicast(skb, net, NETLINK_CB(in_skb).portid, GFP_KERNEL); > errout_ifa: > in6_ifa_put(ifa); > errout: Managing to mix GFP_ATOMIC and GFP_KERNEL almost randomly as you did in this patch is definitely not good. Further more, RTNL is a mutex, held in control path, designed to allow schedules and waiting for memory under pressure. We do not want to encourage GFP_ATOMIC usage in control path. Your patch series gives the wrong signal to developers. I will send a patch against net/ipv4/devinet.c so that we remove GFP_ATOMIC usage there. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: build warning after merge of the wireless-drivers-next tree
Hi all,
On Fri, 8 Jul 2016 11:32:14 +1000 Stephen Rothwell
wrote:
>
> After merging the wireless-drivers-next tree, today's linux-next build
> (arm multi_v7_defconfig, x86_64 allmodconfig) produced this warning:
>
> drivers/net/wireless/marvell/mwifiex/scan.c: In function
> 'mwifiex_cancel_scan':
> drivers/net/wireless/marvell/mwifiex/scan.c:2031:44: warning: passing
> argument 2 of 'cfg80211_scan_done' makes pointer from integer without a cast
> [-Wint-conversion]
> cfg80211_scan_done(priv->scan_request, 1);
> ^
> In file included from include/net/mac80211.h:23:0,
> from drivers/net/wireless/marvell/mwifiex/decl.h:30,
> from drivers/net/wireless/marvell/mwifiex/scan.c:20:
> include/net/cfg80211.h:4104:6: note: expected 'struct cfg80211_scan_info *'
> but argument is of type 'int'
> void cfg80211_scan_done(struct cfg80211_scan_request *request,
> ^
>
> Introduced by commit
>
> a9c790ba23eb ("mwifiex: factor out mwifiex_cancel_scan")
>
> interacting with commit
>
> 1d76250bd34a ("nl80211: support beacon report scanning")
>
> from the net-next (and mac80211-next) tree.
>
> This will need some merge fix patch ... please send me or Dave one.
Of course, this is the conflict I reported against the mac80211-next
tree yesterday (the memory fades :-)) ... I will move the merge fix
patch from that tree to this one.
--
Cheers,
Stephen Rothwell
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
linux-next: build warning after merge of the wireless-drivers-next tree
Hi all,
After merging the wireless-drivers-next tree, today's linux-next build
(arm multi_v7_defconfig, x86_64 allmodconfig) produced this warning:
drivers/net/wireless/marvell/mwifiex/scan.c: In function 'mwifiex_cancel_scan':
drivers/net/wireless/marvell/mwifiex/scan.c:2031:44: warning: passing argument
2 of 'cfg80211_scan_done' makes pointer from integer without a cast
[-Wint-conversion]
cfg80211_scan_done(priv->scan_request, 1);
^
In file included from include/net/mac80211.h:23:0,
from drivers/net/wireless/marvell/mwifiex/decl.h:30,
from drivers/net/wireless/marvell/mwifiex/scan.c:20:
include/net/cfg80211.h:4104:6: note: expected 'struct cfg80211_scan_info *' but
argument is of type 'int'
void cfg80211_scan_done(struct cfg80211_scan_request *request,
^
Introduced by commit
a9c790ba23eb ("mwifiex: factor out mwifiex_cancel_scan")
interacting with commit
1d76250bd34a ("nl80211: support beacon report scanning")
from the net-next (and mac80211-next) tree.
This will need some merge fix patch ... please send me or Dave one.
--
Cheers,
Stephen Rothwell
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the mac80211-next tree with the wireless-drivers-next tree
Hi Kalle, On Thu, 07 Jul 2016 19:10:24 +0300 Kalle Valo wrote: > > Stephen, if it's not too much trouble for you it would be good to CC > linux-wireless on wireless related problems. Not everyone follow lkml > (or linux-next). I have added linux-wireless@vger.kernel.org as a contact for the wireless-drivers and wireless-drivers-next trees. -- Cheers, Stephen Rothwell -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Intel 3168 AC regulatory domain question
Hi folks,
While testing Intel 3168 card. I hit this problem where the driver can't set
regulatory domain properly.
The iwlmvm driver first tries to get regulatory domain from kernel
(iwl_mvm_get_current_regdomain()), and then from bios. Below are the relevant
code from nvm.c, with my debug lines:
886 regd = iwl_mvm_get_current_regdomain(mvm, NULL);
887 if (IS_ERR_OR_NULL(regd))
888 return -EIO;
889
890 IWL_INFO(mvm, "eniacz: regd from kernel=%s\n", regd->alpha2);
891
892 IWL_INFO(mvm, "eniacz: mcc supported=%d\n",
iwl_mvm_is_wifi_mcc_supported(mvm));
893 IWL_INFO(mvm, "eniacz: IWL_UCODE_TLV_API_WIFI_MCC_UPDATE=%d\n",
fw_has_api(&mvm->fw->ucode_capa, IWL_UCODE_TLV_API_WIFI_MCC_UPDATE));
894 IWL_INFO(mvm, "eniacz: IWL_UCODE_TLV_CAPA_LAR_MULTI_MCC=%d\n",
fw_has_capa(&mvm->fw->ucode_capa, IWL_UCODE_TLV_CAPA_LAR_MULTI_MCC));
895 if (iwl_mvm_is_wifi_mcc_supported(mvm) &&
896 !iwl_mvm_get_bios_mcc(mvm, mcc)) {
897 kfree(regd);
898 regd = iwl_mvm_get_regdomain(mvm->hw->wiphy, mcc,
899 MCC_SOURCE_BIOS, NULL);
900 if (IS_ERR_OR_NULL(regd))
901 return -EIO;
902 IWL_INFO(mvm, "eniacz: regd from bios=%s\n", regd->alpha2);
903 }
904
905 retval = regulatory_set_wiphy_regd_sync_rtnl(mvm->hw->wiphy, regd);
906 kfree(regd);
907 return retval;
The first problem is line 890 always returns 00, regardless of what I have set
in cfg80211.
The second problem is that iwlwifi-3168-21.ucode doesn't support MCC, even
though Intel claim 3168 support it. iwlwifi-8000C-14.ucode does support MCC
but that only work with 8260 modules. When I compile code from HEAD, I found
it is requesting version 23 of the firmware (4.6.0 requests 21). But I can't
find v23 firmware anywhere.
My question is how can do I enforce regulatory domain settings on a 3168
module. Either cfg80211 or bios approach will work for me but right now
neither of them is.
Regards/Eniac
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] mwifiex: mask PCIe interrupts before removal
Brian Norris writes: > Hi, > > On Thu, Jun 30, 2016 at 03:21:02PM -0700, Brian Norris wrote: >> The PCIe driver didn't mask the host interrupts before trying to tear >> down. This causes lockups at reboot or rmmod when using MSI-X on 8997, >> since the MSI handler gets confused and locks up the system. >> >> Also tested on 8897, which does not support MSI-X (and wasn't >> experiencing this same bug). No regressions seen there. > > Ping? This is a bugfix, and it'd be nice to either know what's wrong > with it, or see it merged. It's on my queue for 4.8: https://patchwork.kernel.org/patch/9209027/ -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.19.y-ckt 19/99] ath9k: Fix LED polarity for some Mini PCI AR9220 MB92 cards.
3.19.8-ckt23 -stable review patch. If anyone has any objections, please let me
know.
---8<
From: "Vittorio Gambaletta (VittGam)"
commit 0f9edcdd88a993914fa1d1dc369b35dc503979db upstream.
The Wistron DNMA-92 and Compex WLM200NX have inverted LED polarity
(active high instead of active low).
The same PCI Subsystem ID is used by both cards, which are based on
the same Atheros MB92 design.
Cc:
Cc:
Cc:
Signed-off-by: Vittorio Gambaletta
Signed-off-by: Kalle Valo
Signed-off-by: Kamal Mostafa
---
drivers/net/wireless/ath/ath9k/pci.c | 10 ++
1 file changed, 10 insertions(+)
diff --git a/drivers/net/wireless/ath/ath9k/pci.c
b/drivers/net/wireless/ath/ath9k/pci.c
index f009b5b..b9ec8c7 100644
--- a/drivers/net/wireless/ath/ath9k/pci.c
+++ b/drivers/net/wireless/ath/ath9k/pci.c
@@ -28,6 +28,16 @@ static const struct pci_device_id ath_pci_id_table[] = {
{ PCI_VDEVICE(ATHEROS, 0x0024) }, /* PCI-E */
{ PCI_VDEVICE(ATHEROS, 0x0027) }, /* PCI */
{ PCI_VDEVICE(ATHEROS, 0x0029) }, /* PCI */
+
+#ifdef CONFIG_ATH9K_PCOEM
+ /* Mini PCI AR9220 MB92 cards: Compex WLM200NX, Wistron DNMA-92 */
+ { PCI_DEVICE_SUB(PCI_VENDOR_ID_ATHEROS,
+0x0029,
+PCI_VENDOR_ID_ATHEROS,
+0x2096),
+ .driver_data = ATH9K_PCI_LED_ACT_HI },
+#endif
+
{ PCI_VDEVICE(ATHEROS, 0x002A) }, /* PCI-E */
#ifdef CONFIG_ATH9K_PCOEM
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3.19.y-ckt 18/99] ath9k: Add a module parameter to invert LED polarity.
3.19.8-ckt23 -stable review patch. If anyone has any objections, please let me know. ---8< From: "Vittorio Gambaletta (VittGam)" commit cd84042ce9040ad038e958bc67a46fcfc015c736 upstream. The LED can be active high instead of active low on some hardware. Add the led_active_high module parameter. It defaults to -1 to obey platform data as before. Setting the parameter to 1 or 0 will force the LED respectively active high or active low. Cc: Cc: Cc: Signed-off-by: Vittorio Gambaletta Signed-off-by: Kalle Valo Signed-off-by: Kamal Mostafa --- drivers/net/wireless/ath/ath9k/init.c | 7 +++ 1 file changed, 7 insertions(+) diff --git a/drivers/net/wireless/ath/ath9k/init.c b/drivers/net/wireless/ath/ath9k/init.c index a218a00..d7c1a02 100644 --- a/drivers/net/wireless/ath/ath9k/init.c +++ b/drivers/net/wireless/ath/ath9k/init.c @@ -49,6 +49,10 @@ int led_blink; module_param_named(blink, led_blink, int, 0444); MODULE_PARM_DESC(blink, "Enable LED blink on activity"); +static int ath9k_led_active_high = -1; +module_param_named(led_active_high, ath9k_led_active_high, int, 0444); +MODULE_PARM_DESC(led_active_high, "Invert LED polarity"); + static int ath9k_btcoex_enable; module_param_named(btcoex_enable, ath9k_btcoex_enable, int, 0444); MODULE_PARM_DESC(btcoex_enable, "Enable wifi-BT coexistence"); @@ -582,6 +586,9 @@ static int ath9k_init_softc(u16 devid, struct ath_softc *sc, if (ret) return ret; + if (ath9k_led_active_high != -1) + ah->config.led_active_high = ath9k_led_active_high == 1; + /* * Enable WLAN/BT RX Antenna diversity only when: * -- 2.7.4 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: ath10k + iw set bitrates is causing FW crash
On Thu, Jul 7, 2016 at 10:19 PM, Krishna Chaitanya wrote: > Hi, > > I am using ath10k driver with qca988x hw2.0 and trying to limit it to use > VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7). > > But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL > no crash is observed but it still uses MCS9. > > tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339 > > 1) If i disable HW_RATE_CONTROL, will ath10k honor > the mac80211 rates? > > 2) Please find below the dmesg after the crash. > > [ 3879.419737] ath10k_pci :01:00.0: device successfully recovered > [ 3941.919995] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local > choice (Reason: 3=DEAUTH_LEAVING) > [ 3953.665725] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 3955.768675] wlan0: authenticate with 74:d0:2b:41:e4:b4 > [ 3955.768688] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3 > [ 3955.776460] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3) > [ 3955.777014] wlan0: authenticated > [ 3955.781060] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3) > [ 3955.782124] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11 > status=0 aid=2) > [ 3955.783147] wlan0: associated > [ 3955.783213] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > [ 3959.053601] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local > choice (Reason: 3=DEAUTH_LEAVING) > [ 3964.025669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready > [ 3967.104520] wlan0: authenticate with 74:d0:2b:41:e4:b4 > [ 3967.104533] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3 > [ 3967.112366] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3) > [ 3967.112905] wlan0: authenticated > [ 3967.113166] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3) > [ 3967.114248] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11 > status=0 aid=2) > [ 3967.115327] wlan0: associated > [ 3967.115357] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready > [ 3976.110218] ath10k_pci :01:00.0: firmware crashed! (uuid > bfab5915-ae19-40b1-be67-544d909779ab) > [ 3976.110226] ath10k_pci :01:00.0: qca988x hw2.0 target > 0x4100016c chip_id 0x043222ff sub : > [ 3976.110228] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 > tracing 1 dfs 0 testmode 0 > [ 3976.110467] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api > 5 features no-p2p,raw-mode crc32 b8d50af5 > [ 3976.110472] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A > crc32 bebc7c08 > [ 3976.110475] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 > cal otp max-sta 128 raw 0 hwcrypto 1 > [ 3976.112483] ath10k_pci :01:00.0: firmware register dump: > [ 3976.112485] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 > 0x009BF931 0x00955B31 > [ 3976.112487] ath10k_pci :01:00.0: [04]: 0x009BF931 0x00060530 > 0x0010 0x > [ 3976.112490] ath10k_pci :01:00.0: [08]: 0x0044D9B8 0xC001 > 0x 0x0005 > [ 3976.112492] ath10k_pci :01:00.0: [12]: 0x0009 0x > 0x00957F04 0x00957F12 > [ 3976.112494] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D > 0x 0x > [ 3976.112496] ath10k_pci :01:00.0: [20]: 0x409BF931 0x0040AA44 > 0x00420854 0x00440198 > [ 3976.112498] ath10k_pci :01:00.0: [24]: 0x809BF9A1 0x0040AAA4 > 0x00789518 0xC09BF931 > [ 3976.112500] ath10k_pci :01:00.0: [28]: 0x809B837F 0x0040AAC4 > 0x0044D9B8 0x05DC > [ 3976.112502] ath10k_pci :01:00.0: [32]: 0x809B8555 0x0040AAE4 > 0x0044D9A0 0x0100 > [ 3976.112504] ath10k_pci :01:00.0: [36]: 0x809A0DF5 0x0040AB04 > 0x0043EAA8 0x0040AD14 > [ 3976.112506] ath10k_pci :01:00.0: [40]: 0x809896F9 0x0040AB24 > 0x0043EAA8 0x0040AD14 > [ 3976.112508] ath10k_pci :01:00.0: [44]: 0x809B5ACC 0x0040AB44 > 0x009C575C 0x0043EAA8 > [ 3976.112510] ath10k_pci :01:00.0: [48]: 0x809B1C74 0x0040ADA4 > 0x0040 0x00416DEC > [ 3976.112512] ath10k_pci :01:00.0: [52]: 0x809BFB39 0x0040ADE4 > 0x0040AE08 0x00411F80 > [ 3976.112514] ath10k_pci :01:00.0: [56]: 0x809486FA 0x0040AE04 > 0x0001 0x > [ 3976.195917] ieee80211 phy0: Hardware restart was requested > [ 3977.561878] ath10k_pci :01:00.0: device successfully recovered > [ 8494.632109] ath10k_pci :01:00.0: firmware crashed! (uuid > 5b6f2fe0-1a2c-4485-a7d5-64705ca051a2) > [ 8494.632116] ath10k_pci :01:00.0: qca988x hw2.0 target > 0x4100016c chip_id 0x043222ff sub : > [ 8494.632119] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 > tracing 1 dfs 0 testmode 0 > [ 8494.632357] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api > 5 features no-p2p,raw-mode crc32 b8d50af5 > [ 8494.632362] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A > crc32 bebc7c08 > [ 8494.632364] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 > cal otp max-sta 128 raw 0 hwcrypto 1 > [ 8494.634373] ath10k_pci :01:00.0: firmware register dump: > [ 8494.634376] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 > 0x009BF931 0x00955B31 > [ 84
Re: [PATCH] mwifiex: mask PCIe interrupts before removal
Hi,
On Thu, Jun 30, 2016 at 03:21:02PM -0700, Brian Norris wrote:
> The PCIe driver didn't mask the host interrupts before trying to tear
> down. This causes lockups at reboot or rmmod when using MSI-X on 8997,
> since the MSI handler gets confused and locks up the system.
>
> Also tested on 8897, which does not support MSI-X (and wasn't
> experiencing this same bug). No regressions seen there.
Ping? This is a bugfix, and it'd be nice to either know what's wrong
with it, or see it merged.
Regards,
Brian
> Signed-off-by: Brian Norris
> ---
> drivers/net/wireless/marvell/mwifiex/pcie.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/drivers/net/wireless/marvell/mwifiex/pcie.c
> b/drivers/net/wireless/marvell/mwifiex/pcie.c
> index 0c7937eb6b77..af98371dc2af 100644
> --- a/drivers/net/wireless/marvell/mwifiex/pcie.c
> +++ b/drivers/net/wireless/marvell/mwifiex/pcie.c
> @@ -440,6 +440,11 @@ static int mwifiex_pcie_disable_host_int(struct
> mwifiex_adapter *adapter)
> return 0;
> }
>
> +static void mwifiex_pcie_disable_host_int_noerr(struct mwifiex_adapter
> *adapter)
> +{
> + WARN_ON(mwifiex_pcie_disable_host_int(adapter));
> +}
> +
> /*
> * This function enables the host interrupt.
> *
> @@ -2945,6 +2950,7 @@ static struct mwifiex_if_ops pcie_ops = {
> .register_dev = mwifiex_register_dev,
> .unregister_dev = mwifiex_unregister_dev,
> .enable_int = mwifiex_pcie_enable_host_int,
> + .disable_int = mwifiex_pcie_disable_host_int_noerr,
> .process_int_status = mwifiex_process_int_status,
> .host_to_card = mwifiex_pcie_host_to_card,
> .wakeup = mwifiex_pm_wakeup_card,
> --
> 2.8.0.rc3.226.g39d4020
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
ath10k + iw set bitrates is causing FW crash
Hi, I am using ath10k driver with qca988x hw2.0 and trying to limit it to use VHT MCS0-7 (iw set bitrates vht-mcs-5 2:0-7). But the command it causing a FW crash, if it disable HW_HAS_RATE_CONTROL no crash is observed but it still uses MCS9. tree: wireless-drivers-next: commit#535633a5ba4ea2504fa6c33176633becf0e59339 1) If i disable HW_RATE_CONTROL, will ath10k honor the mac80211 rates? 2) Please find below the dmesg after the crash. [ 3879.419737] ath10k_pci :01:00.0: device successfully recovered [ 3941.919995] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local choice (Reason: 3=DEAUTH_LEAVING) [ 3953.665725] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 3955.768675] wlan0: authenticate with 74:d0:2b:41:e4:b4 [ 3955.768688] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3 [ 3955.776460] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3) [ 3955.777014] wlan0: authenticated [ 3955.781060] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3) [ 3955.782124] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11 status=0 aid=2) [ 3955.783147] wlan0: associated [ 3955.783213] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 3959.053601] wlan0: deauthenticating from 74:d0:2b:41:e4:b4 by local choice (Reason: 3=DEAUTH_LEAVING) [ 3964.025669] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready [ 3967.104520] wlan0: authenticate with 74:d0:2b:41:e4:b4 [ 3967.104533] ieee80211_determine_chantype:306 enter..: cwid:3 vht_cwid:3 [ 3967.112366] wlan0: send auth to 74:d0:2b:41:e4:b4 (try 1/3) [ 3967.112905] wlan0: authenticated [ 3967.113166] wlan0: associate with 74:d0:2b:41:e4:b4 (try 1/3) [ 3967.114248] wlan0: RX AssocResp from 74:d0:2b:41:e4:b4 (capab=0x11 status=0 aid=2) [ 3967.115327] wlan0: associated [ 3967.115357] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready [ 3976.110218] ath10k_pci :01:00.0: firmware crashed! (uuid bfab5915-ae19-40b1-be67-544d909779ab) [ 3976.110226] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub : [ 3976.110228] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0 [ 3976.110467] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api 5 features no-p2p,raw-mode crc32 b8d50af5 [ 3976.110472] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 3976.110475] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 [ 3976.112483] ath10k_pci :01:00.0: firmware register dump: [ 3976.112485] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 0x009BF931 0x00955B31 [ 3976.112487] ath10k_pci :01:00.0: [04]: 0x009BF931 0x00060530 0x0010 0x [ 3976.112490] ath10k_pci :01:00.0: [08]: 0x0044D9B8 0xC001 0x 0x0005 [ 3976.112492] ath10k_pci :01:00.0: [12]: 0x0009 0x 0x00957F04 0x00957F12 [ 3976.112494] ath10k_pci :01:00.0: [16]: 0x00958080 0x0094085D 0x 0x [ 3976.112496] ath10k_pci :01:00.0: [20]: 0x409BF931 0x0040AA44 0x00420854 0x00440198 [ 3976.112498] ath10k_pci :01:00.0: [24]: 0x809BF9A1 0x0040AAA4 0x00789518 0xC09BF931 [ 3976.112500] ath10k_pci :01:00.0: [28]: 0x809B837F 0x0040AAC4 0x0044D9B8 0x05DC [ 3976.112502] ath10k_pci :01:00.0: [32]: 0x809B8555 0x0040AAE4 0x0044D9A0 0x0100 [ 3976.112504] ath10k_pci :01:00.0: [36]: 0x809A0DF5 0x0040AB04 0x0043EAA8 0x0040AD14 [ 3976.112506] ath10k_pci :01:00.0: [40]: 0x809896F9 0x0040AB24 0x0043EAA8 0x0040AD14 [ 3976.112508] ath10k_pci :01:00.0: [44]: 0x809B5ACC 0x0040AB44 0x009C575C 0x0043EAA8 [ 3976.112510] ath10k_pci :01:00.0: [48]: 0x809B1C74 0x0040ADA4 0x0040 0x00416DEC [ 3976.112512] ath10k_pci :01:00.0: [52]: 0x809BFB39 0x0040ADE4 0x0040AE08 0x00411F80 [ 3976.112514] ath10k_pci :01:00.0: [56]: 0x809486FA 0x0040AE04 0x0001 0x [ 3976.195917] ieee80211 phy0: Hardware restart was requested [ 3977.561878] ath10k_pci :01:00.0: device successfully recovered [ 8494.632109] ath10k_pci :01:00.0: firmware crashed! (uuid 5b6f2fe0-1a2c-4485-a7d5-64705ca051a2) [ 8494.632116] ath10k_pci :01:00.0: qca988x hw2.0 target 0x4100016c chip_id 0x043222ff sub : [ 8494.632119] ath10k_pci :01:00.0: kconfig debug 1 debugfs 1 tracing 1 dfs 0 testmode 0 [ 8494.632357] ath10k_pci :01:00.0: firmware ver 10.2.4.70.9-2 api 5 features no-p2p,raw-mode crc32 b8d50af5 [ 8494.632362] ath10k_pci :01:00.0: board_file api 1 bmi_id N/A crc32 bebc7c08 [ 8494.632364] ath10k_pci :01:00.0: htt-ver 2.1 wmi-op 5 htt-op 2 cal otp max-sta 128 raw 0 hwcrypto 1 [ 8494.634373] ath10k_pci :01:00.0: firmware register dump: [ 8494.634376] ath10k_pci :01:00.0: [00]: 0x4100016C 0x15B3 0x009BF931 0x00955B31 [ 8494.634378] ath10k_pci :01:00.0: [04]: 0x009BF931 0x00060530 0x0010 0x [ 8494.634380] ath10k_pci :01:00.0: [08]: 0x0044D9B8 0xC001 0x 0x0005 [ 8494.634382] ath10k_pci :01:00.0: [12]: 0x0009 0x 0x00957F04
Re: [PATCH] ath10k: disable wake_tx_queue for older devices
Michal Kazior writes: > Ideally wake_tx_queue should be used regardless as > it is a requirement for reducing bufferbloat and > implementing airtime fairness in the future. > > However some setups (typically low-end platforms > hosting QCA988X) suffer performance regressions > with the current wake_tx_queue implementation. > Therefore disable it unless it is really > beneficial with current codebase (which is when > firmware supports smart pull-push tx scheduling). > > Signed-off-by: Michal Kazior I think it's too late to send this to 4.7 anymore (and this due to my vacation). So I'm planning to queue this to 4.8, but if the feedback is positive we can always send this to a 4.7 stable release. -- Kalle Valo-- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: linux-next: manual merge of the mac80211-next tree with the wireless-drivers-next tree
(Adding linux-wireless)
Stephen Rothwell writes:
> Hi Johannes,
>
> Today's linux-next merge of the mac80211-next tree got a conflict in:
>
> drivers/net/wireless/marvell/mwifiex/cmdevt.c
>
> between commit:
>
> a9c790ba23eb ("mwifiex: factor out mwifiex_cancel_scan")
>
> from the wireless-drivers-next tree and commit:
>
> 1d76250bd34a ("nl80211: support beacon report scanning")
>
> from the mac80211-next tree.
>
> I fixed it up (I used the wireless-drivers-next tree version of this file
> and then added the following merge fix patch) and can carry the fix as
> necessary. This is now fixed as far as linux-next is concerned, but any
> non trivial conflicts should be mentioned to your upstream maintainer
> when your tree is submitted for merging. You may also want to consider
> cooperating with the maintainer of the conflicting tree to minimise any
> particularly complex conflicts.
Thanks. When I send my pull request to Dave I'll let him know about this
conflict and propose to use your patch as the resolution.
Stephen, if it's not too much trouble for you it would be good to CC
linux-wireless on wireless related problems. Not everyone follow lkml
(or linux-next).
--
Kalle Valo
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[bug report] nfc: st-nci: Move loopback usage from HCI to NCI
Hello Christophe Ricard,
The patch 3aacd7fe552b: "nfc: st-nci: Move loopback usage from HCI to
NCI" from Apr 30, 2016, leads to the following static checker warning:
drivers/nfc/st-nci/vendor_cmds.c:351 st_nci_loopback()
error: potentially dereferencing uninitialized 'skb'.
drivers/nfc/st-nci/vendor_cmds.c
336 static int st_nci_loopback(struct nfc_dev *dev, void *data,
337 size_t data_len)
338 {
339 int r;
340 struct sk_buff *msg, *skb;
341 struct nci_dev *ndev = nfc_get_drvdata(dev);
342
343 if (data_len <= 0)
344 return -EPROTO;
345
346 r = nci_nfcc_loopback(ndev, data, data_len, &skb);
347 if (r < 0)
348 return r;
349
350 msg = nfc_vendor_cmd_alloc_reply_skb(dev, ST_NCI_VENDOR_OUI,
351 LOOPBACK, skb->len);
This bug is slightly complicated to analyze.
The complaint is basically that nci_nfcc_loopback() can return positive
error codes like ENOMEM instead of -ENOMEM. The reason is that
nci_req_complete() is normally takes some sort of custom positive
error code like NCI_STATUS_REJECTED. Later on we cast transform it to
a negative kernel error code.
But the two callers in nci_hci_data_received_cb() which pass regular
kernel error codes to nci_req_complete().
352 if (!msg) {
353 r = -ENOMEM;
354 goto free_skb;
355 }
356
357 if (nla_put(msg, NFC_ATTR_VENDOR_DATA, skb->len, skb->data)) {
358 kfree_skb(msg);
359 r = -ENOBUFS;
360 goto free_skb;
361 }
362
363 r = nfc_vendor_cmd_reply(msg);
364 free_skb:
365 kfree_skb(skb);
366 return r;
367 }
regards,
dan carpenter
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] wcn36xx: Silence error about unsupported smd event 188
Sometimes the firmware sends a HAL_DEL_BA_IND, the prima driver silently
ignore this message so let's do the same to silence the error message.
Cc: Nicolas Dechesne
Signed-off-by: Bjorn Andersson
---
drivers/net/wireless/ath/wcn36xx/smd.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/net/wireless/ath/wcn36xx/smd.c
b/drivers/net/wireless/ath/wcn36xx/smd.c
index e8b630c4f11e..3d56a3f236f9 100644
--- a/drivers/net/wireless/ath/wcn36xx/smd.c
+++ b/drivers/net/wireless/ath/wcn36xx/smd.c
@@ -2226,6 +2226,7 @@ static void wcn36xx_smd_rsp_process(struct wcn36xx *wcn,
void *buf, size_t len)
case WCN36XX_HAL_COEX_IND:
case WCN36XX_HAL_AVOID_FREQ_RANGE_IND:
+ case WCN36XX_HAL_DEL_BA_IND:
case WCN36XX_HAL_OTA_TX_COMPL_IND:
case WCN36XX_HAL_MISSED_BEACON_IND:
case WCN36XX_HAL_DELETE_STA_CONTEXT_IND:
@@ -2273,6 +2274,7 @@ static void wcn36xx_ind_smd_work(struct work_struct *work)
switch (msg_header->msg_type) {
case WCN36XX_HAL_COEX_IND:
+ case WCN36XX_HAL_DEL_BA_IND:
case WCN36XX_HAL_AVOID_FREQ_RANGE_IND:
break;
case WCN36XX_HAL_OTA_TX_COMPL_IND:
--
2.5.0
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] cfg80211/nl80211: add wifi tx power mode switching support
Hi Johannes, Thanks for the reply. You are right that the physical antenna does not change. When I refer to 'calibration data', it actually corresponding to how mwifiex adjust the per-band tx power. For mwifiex, the per-band tx power is pre-calculated based on need, and stored in DT, a vendor command or std nl80211 message is sent to tell the driver to switch between two set of "calibration data". I'm aware that iwl7000 is using a vendor command to do this as well, but instead of pre-calculate required tx power info, the tx value can be passed along with the vendor command message. This patch was sent originally to standardize the requirement of sending a vendor command to the driver (so it'll be a standard nl80211 message). However, we have decided to move along with vendor command for both mwifiex and nl80211, so this patch is not needed anymore. Thanks for the comments! Wei-Ning On Tue, Jun 28, 2016 at 6:57 PM, Johannes Berg wrote: > On Thu, 2016-05-12 at 17:34 +0800, Wei-Ning Huang wrote: >> >> Johannes, I feel like being able to set calibration data at runtime >> is something common to all wireless drivers, so instead of using >> vendor commands what do you think if I pass the calibration data name >> instead of using those magic constants? This way, userspace does not >> need to know the details of what band/range power limit the driver >> supports. It allows for flexible driver side implementation and >> easier for userspace to control. >> > > Sorry - I dropped this thread accidentally. > > I'm not really sure I understand the situation fully, but right now to > me this seems very strange. > > The physical antennas probably don't really change between "clamshell" > and "tablet" mode, do the physical radiation properties change enough > to actually require different *calibration*? To me, that sounds very > strange. > > Assuming they don't really change fundamentally, then I understand the > need to set different power levels, per band/channel/whatever > granularity. But that can be achieved in very different ways, and in > fact if you look at Chrome then for our iwl7000 driver there we do have > a command to do something similar (currently a vendor command, but that > can be changed) without ever changing the *calibration*. > > So to me, the whole premise of the patch is confusing and/or wrong. > > johannes -- Wei-Ning Huang, 黃偉寧 | Software Engineer, Google Inc., Taiwan | wnhu...@google.com | Cell: +886 910-380678 -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm, nvram_file_name dt property
On Thursday, July 7, 2016 11:16:59 AM CEST Arend Van Spriel wrote: > On 7-7-2016 10:46, Arnd Bergmann wrote: > > On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote: > >> On 6-7-2016 15:42, Arnd Bergmann wrote: > >>> On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote: > On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann wrote: > > I'm a bit confused by the interdependencies now. You say that there are > > board ID/rev values stored in OTP. What exactly prevents us from just > > using those to generate a file name to look up the nvram file on disk > > for the remaining values? > > > > Do we require the firmware to be running before we can read the OTP, > > or are there cases where the board ID in OTP is wrong or missing? > > Well, both. Primarily we need firmware running to get the info. If board > ID is missing in OTP the value from nvram file is used. If board ID in > OTP is wrong we are screwed Ok. > > If we can't rely on OTP for one of those reasons and instead add two > > properties for boardtype/boardrev, I don't think that requires a > > change of the compatible string, we would just document those two > > as optional properties. > > Right. I suppose the bindings update and driver update should preferably > be in the same kernel release although bindings are supposedly OS agnostic. It's a one-way dependency, we shouldn't add the kernel code handling the property without having agreed on and updated the binding first. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
On 7-7-2016 10:46, Arnd Bergmann wrote: > On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote: >> On 6-7-2016 15:42, Arnd Bergmann wrote: >>> On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote: On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann wrote: >>> All existing uses of the model property in arch/arm/boot/dts and most of >>> the ones in arch/powerpc/boot/dts are against the intended usage in >>> one way or another, but adding different kind of incorrect usage won't >>> improve that. >>> >>> The only way I can see the model property being used correctly would >>> be to have it match the first entry in the compatible property, but >>> that is completely redundant, so we tend to omit it, except for the >>> root node in which it is required. For the root node however, the >>> historic practice that has crept in on ARM is to put something completely >>> different in there, which is a human-readable description of the >>> machine rather than something we can use as a unique indentifier. >>> >>> I'd just consider the "model" property burned, and not use it for anything >>> that doesn't already use it, just like we handle "device_type": a few >>> things require it, nothing else should use it. >> >> If that is the agreed approach in devicetree arena I am fine with it. I >> have been unaware of this and just looked at the suggestion from Jonas >> seeing a solution to the problem at hand. > > I don't think it has been discussed or decided before as the question > has not come up, so for now this is my personal view. Maybe one of > the devicetree maintainers can comment on this. > >>> I agree with your point that the "compatible" property in case of brcmfmac >>> is really odd because it is not required to identify the hardware when >>> the SDIO device identification is sufficient, and we just need it to guard >>> the definition of the other properties. However it seems that now we >>> actually do need to identify the hardware because we cannot read the >>> board ID and revision that is supposed to come from nvram but also needed >>> to read the nvram contents from a file. >> >> The board ID and rev in the nvram may not be used if the device has >> these stored in OTP. However, the problem is that the device need >> firmware+nvram loaded into it before we can start the firmware on the >> device. Now if we were to add boardtype and boardrev properties in the >> binding to identify the hardware, I suppose a new compatible value would >> be required. > > I'm a bit confused by the interdependencies now. You say that there are > board ID/rev values stored in OTP. What exactly prevents us from just > using those to generate a file name to look up the nvram file on disk > for the remaining values? > > Do we require the firmware to be running before we can read the OTP, > or are there cases where the board ID in OTP is wrong or missing? Well, both. Primarily we need firmware running to get the info. If board ID is missing in OTP the value from nvram file is used. If board ID in OTP is wrong we are screwed :-p > If we can't rely on OTP for one of those reasons and instead add two > properties for boardtype/boardrev, I don't think that requires a > change of the compatible string, we would just document those two > as optional properties. Right. I suppose the bindings update and driver update should preferably be in the same kernel release although bindings are supposedly OS agnostic. Regards, Arend -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property
On Wednesday, July 6, 2016 9:19:41 PM CEST Arend Van Spriel wrote: > On 6-7-2016 15:42, Arnd Bergmann wrote: > > On Wednesday, July 6, 2016 10:08:55 AM CEST Arend Van Spriel wrote: > >> On Tue, Jul 5, 2016 at 3:43 PM, Arnd Bergmann wrote: > > All existing uses of the model property in arch/arm/boot/dts and most of > > the ones in arch/powerpc/boot/dts are against the intended usage in > > one way or another, but adding different kind of incorrect usage won't > > improve that. > > > > The only way I can see the model property being used correctly would > > be to have it match the first entry in the compatible property, but > > that is completely redundant, so we tend to omit it, except for the > > root node in which it is required. For the root node however, the > > historic practice that has crept in on ARM is to put something completely > > different in there, which is a human-readable description of the > > machine rather than something we can use as a unique indentifier. > > > > I'd just consider the "model" property burned, and not use it for anything > > that doesn't already use it, just like we handle "device_type": a few > > things require it, nothing else should use it. > > If that is the agreed approach in devicetree arena I am fine with it. I > have been unaware of this and just looked at the suggestion from Jonas > seeing a solution to the problem at hand. I don't think it has been discussed or decided before as the question has not come up, so for now this is my personal view. Maybe one of the devicetree maintainers can comment on this. > > I agree with your point that the "compatible" property in case of brcmfmac > > is really odd because it is not required to identify the hardware when > > the SDIO device identification is sufficient, and we just need it to guard > > the definition of the other properties. However it seems that now we > > actually do need to identify the hardware because we cannot read the > > board ID and revision that is supposed to come from nvram but also needed > > to read the nvram contents from a file. > > The board ID and rev in the nvram may not be used if the device has > these stored in OTP. However, the problem is that the device need > firmware+nvram loaded into it before we can start the firmware on the > device. Now if we were to add boardtype and boardrev properties in the > binding to identify the hardware, I suppose a new compatible value would > be required. I'm a bit confused by the interdependencies now. You say that there are board ID/rev values stored in OTP. What exactly prevents us from just using those to generate a file name to look up the nvram file on disk for the remaining values? Do we require the firmware to be running before we can read the OTP, or are there cases where the board ID in OTP is wrong or missing? If we can't rely on OTP for one of those reasons and instead add two properties for boardtype/boardrev, I don't think that requires a change of the compatible string, we would just document those two as optional properties. Arnd -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
