Re: [linux-sunxi] Re: [PATCH 1/4] brcmfmac: Add brcm,nvram_file_name dt property

2016-07-17 Thread Rob Herring 
On Thu, Jul 07, 2016 at 10:46:28AM +0200, 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.

Back from vacation and getting caught up.

I agree with Arnd here. In my view model is the OEM branding on the 
device, compatible is the h/w. If you have different firmware related 
files, that goes beyond OEM branding.

Rob
--
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] ath9k: fix GPIO mask for AR9462 and AR9565

2016-07-17 Thread Stefan Lippers-Hollmann 
Hi

On 2016-06-03, miaoq...@codeaurora.org wrote:
> From: Miaoqing Pan 
> 
> The incorrect GPIO mask cause kernel warning, when AR9462 access GPIO11.
> Also fix the mask for AR9565.
[...]

I think I'm seeing a very similar issue on AR5008/ AR5416+AR2133 and 
4.7-rc7 (mainline v4.7-rc7-92-g47ef4ad, to be exact).

[4.958874] ath9k :02:02.0: enabling device ( -> 0002)
[...]
[5.401086] [ cut here ]
[5.401093] WARNING: CPU: 1 PID: 1159 at 
/build/linux-aptosid-4.7~rc7/drivers/net/wireless/ath/ath9k/hw.c:2776 
ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
[5.401116] Modules linked in: iTCO_wdt gpio_ich iTCO_vendor_support evdev 
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp ir_lirc_codec 
lirc_dev kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul rtl2832_sdr 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev 
ghash_clmulni_intel fc0013 rtl2832 i2c_mux regmap_i2c sha256_ssse3 
sha256_generic drbg ansi_cprng rc_medion_x10_digitainer dvb_usb_rtl28xxu 
dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb aesni_intel dvb_core aes_x86_64 lrw 
ati_remote media gf128mul glue_helper ablk_helper cryptd intel_cstate 
intel_rapl_perf snd_hda_codec_hdmi(+) i915 snd_hda_codec_realtek 
snd_hda_codec_generic pcspkr serio_raw i2c_i801 ath9k(+) ath9k_common video 
ath9k_hw i2c_algo_bit drm_kms_helper ath snd_hda_intel drm snd_hda_codec 
mac80211 snd_hda_core
[5.401135]  snd_hwdep snd_pcm cfg80211 i2c_core intel_gtt rfkill snd_timer 
syscopyarea lpc_ich sysfillrect snd sg sysimgblt mfd_core mei_me soundcore 
fb_sys_fops mei nuvoton_cir floppy(+) rc_core button w83627ehf hwmon_vid 
parport_pc ppdev lp parport autofs4 ext4 crc16 jbd2 mbcache hid_generic usbhid 
hid dm_mod sd_mod sr_mod cdrom ohci_pci crc32c_intel psmouse r8169 ahci libahci 
libata scsi_mod xhci_pci xhci_hcd ohci_hcd e100 mii ehci_pci ehci_hcd usbcore 
usb_common e1000e ptp pps_core fjes
[5.401137] CPU: 1 PID: 1159 Comm: systemd-udevd Not tainted 
4.7.0-rc7-aptosid-amd64 #1 aptosid 4.7~rc7-1~git92.slh.3
[5.401138] Hardware name:  /DH67CL, BIOS 
BLH6710H.86A.0160.2012.1204.1156 12/04/2012
[5.401140]  0286 f912d633 81290fd3 

[5.401141]   81063fd4 88040c6dc018 

[5.401143]  0002  0100 
88040c6dc018
[5.401143] Call Trace:
[5.401148]  [] ? dump_stack+0x5c/0x79
[5.401150]  [] ? __warn+0xb4/0xd0
[5.401153]  [] ? ath9k_hw_gpio_get+0x148/0x1a0 [ath9k_hw]
[5.401156]  [] ? ath9k_hw_fill_cap_info+0x163/0x830 
[ath9k_hw]
[5.401159]  [] ? ath9k_hw_init+0x664/0xb10 [ath9k_hw]
[5.401167]  [] ? ath9k_init_device+0x4df/0xe00 [ath9k]
[5.401170]  [] ? request_threaded_irq+0xf1/0x1a0
[5.401176]  [] ? ath_pci_probe+0x1c9/0x370 [ath9k]
[5.401178]  [] ? local_pci_probe+0x3a/0x90
[5.401179]  [] ? pci_match_device+0xcf/0xf0
[5.401180]  [] ? pci_device_probe+0xfb/0x140
[5.401183]  [] ? driver_probe_device+0x1ed/0x2b0
[5.401184]  [] ? __driver_attach+0x8f/0xa0
[5.401185]  [] ? driver_probe_device+0x2b0/0x2b0
[5.401186]  [] ? bus_for_each_dev+0x62/0xb0
[5.401188]  [] ? bus_add_driver+0x19a/0x210
[5.401189]  [] ? 0xa0718000
[5.401190]  [] ? driver_register+0x52/0xc0
[5.401195]  [] ? ath9k_init+0x5/0x34 [ath9k]
[5.401197]  [] ? do_one_initcall+0x47/0x180
[5.401199]  [] ? do_init_module+0x51/0x1b9
[5.401201]  [] ? load_module+0x1f77/0x23a0
[5.401202]  [] ? __symbol_put+0x80/0x80
[5.401205]  [] ? security_capable+0x3c/0x50
[5.401207]  [] ? SYSC_finit_module+0xc2/0xd0
[5.401210]  [] ? entry_SYSCALL_64_fastpath+0x1a/0xa4
[5.401211] ---[ end trace ac762697fb0d9f1d ]---
[5.401211] [ cut here ]
[5.401214] WARNING: CPU: 1 PID: 1159 at 
/build/linux-aptosid-4.7~rc7/drivers/net/wireless/ath/ath9k/hw.c:2796 
ath9k_hw_gpio_get+0xb4/0x1a0 [ath9k_hw]
[5.401234] Modules linked in: iTCO_wdt gpio_ich iTCO_vendor_support evdev 
intel_rapl x86_pkg_temp_thermal intel_powerclamp coretemp ir_lirc_codec 
lirc_dev kvm_intel kvm irqbypass crct10dif_pclmul crc32_pclmul rtl2832_sdr 
videobuf2_vmalloc videobuf2_memops videobuf2_v4l2 videobuf2_core videodev 
ghash_clmulni_intel fc0013 rtl2832 i2c_mux regmap_i2c sha256_ssse3 
sha256_generic drbg ansi_cprng rc_medion_x10_digitainer dvb_usb_rtl28xxu 
dvb_usb_v2 dvb_usb_dw2102(+) dvb_usb aesni_intel dvb_core aes_x86_64 lrw 
ati_remote media gf128mul glue_helper ablk_helper cryptd intel_cstate 
intel_rapl_perf snd_hda_codec_hdmi(+) i915 snd_hda_codec_realtek 
snd_hda_codec_generic pcspkr serio_raw i2c_i801 ath9k(+) ath9k_common video 
ath9k_hw i2c_algo_bit drm_kms_helper ath snd_hda_intel drm snd_hda_codec 
mac80211 snd_hda_core
[5.401254]  snd_hwdep snd_pcm cfg80211 i2c_core intel_gtt rfkill snd_timer 
syscopyarea lpc_ich sysfillrect snd sg sysimgblt mfd_core

[PATCH] cfg80211: fix missing break in NL8211_CHAN_WIDTH_80P80 case

2016-07-17 Thread Colin King 
From: Colin Ian King 

The switch on chandef->width is missing a break on the
NL8211_CHAN_WIDTH_80P80 case; currently we get a WARN_ON when
center_freq2 is non-zero because of the missing break.

Signed-off-by: Colin Ian King 
---
 net/wireless/chan.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/net/wireless/chan.c b/net/wireless/chan.c
index b0e11b6..0f50622 100644
--- a/net/wireless/chan.c
+++ b/net/wireless/chan.c
@@ -513,6 +513,7 @@ static bool cfg80211_chandef_dfs_available(struct wiphy 
*wiphy,
r = cfg80211_get_chans_dfs_available(wiphy,
 chandef->center_freq2,
 width);
+   break;
default:
WARN_ON(chandef->center_freq2);
break;
-- 
2.8.1

--
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 v5] wlcore: spi: add wl18xx support

2016-07-17 Thread Reizer, Eyal 
Add support for using with both wl12xx and wl18xx.

- all wilink family needs special init command for entering wspi mode.
  extra clock cycles should be sent after the spi init command while the
  cs pin is high.
- Use inverted chip select for sending a dummy 4 bytes command that
  completes the init stage.

Signed-off-by: Eyal Reizer 
Acked-by: Rob Herring 
---
v1->v2:update device tree bindings configuration
v2->v3:revert from manual gpio manipulation. use inverted chip select 
instead for sending the extra init cycle which, achieves the same hardware 
purpose.
update device tree bindings docucmentation accordingly
v3->v4: Remove redundant data form binding documentation and fix chip 
select number mismatch in wl1271 example
v4->v5: Rebase on top of head of wireless-drivers-next

 .../bindings/net/wireless/ti,wlcore,spi.txt|  41 +--
 drivers/net/wireless/ti/wlcore/spi.c   | 123 ++---
 2 files changed, 137 insertions(+), 27 deletions(-)

diff --git a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt 
b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
index 9180724..8f9ced0 100644
--- a/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
+++ b/Documentation/devicetree/bindings/net/wireless/ti,wlcore,spi.txt
@@ -1,19 +1,30 @@
-* Texas Instruments wl1271 wireless lan controller
+* Texas Instruments wl12xx/wl18xx wireless lan controller

-The wl1271 chip can be connected via SPI or via SDIO. This
+The wl12xx/wl18xx chips can be connected via SPI or via SDIO. This
 document describes the binding for the SPI connected chip.

 Required properties:
-- compatible :  Should be "ti,wl1271"
+- compatible :  Should be one of the following:
+* "ti,wl1271"
+* "ti,wl1273"
+* "ti,wl1281"
+* "ti,wl1283"
+* "ti,wl1801"
+* "ti,wl1805"
+* "ti,wl1807"
+* "ti,wl1831"
+* "ti,wl1835"
+* "ti,wl1837"
 - reg : Chip select address of device
 - spi-max-frequency :   Maximum SPI clocking speed of device in Hz
-- ref-clock-frequency : Reference clock frequency
 - interrupt-parent, interrupts :
 Should contain parameters for 1 interrupt line.
 Interrupt parameters: parent, line number, type.
-- vwlan-supply :Point the node of the regulator that powers/enable the 
wl1271 chip
+- vwlan-supply :Point the node of the regulator that powers/enable the
+wl12xx/wl18xx chip

 Optional properties:
+- ref-clock-frequency : Reference clock frequency (should be set for 
+wl12xx)
 - clock-xtal :  boolean, clock is generated from XTAL

 - Please consult Documentation/devicetree/bindings/spi/spi-bus.txt
@@ -21,16 +32,28 @@ Optional properties:

 Examples:

+For wl12xx family:
  {
-   wl1271@1 {
+   wlcore: wlcore@1 {
compatible = "ti,wl1271";
-
reg = <1>;
spi-max-frequency = <4800>;
-   clock-xtal;
-   ref-clock-frequency = <3840>;
interrupt-parent = <>;
interrupts = <8 IRQ_TYPE_LEVEL_HIGH>;
vwlan-supply = <_fixed>;
+   clock-xtal;
+   ref-clock-frequency = <3840>;
+   };
+};
+
+For wl18xx family:
+ {
+   wlcore: wlcore@0 {
+   compatible = "ti,wl1835";
+   reg = <0>;
+   spi-max-frequency = <4800>;
+   interrupt-parent = <>;
+   interrupts = <27 IRQ_TYPE_EDGE_RISING>;
+   vwlan-supply = <_fixed>;
};
 };
diff --git a/drivers/net/wireless/ti/wlcore/spi.c 
b/drivers/net/wireless/ti/wlcore/spi.c
index cea9443..73fbcf1 100644
--- a/drivers/net/wireless/ti/wlcore/spi.c
+++ b/drivers/net/wireless/ti/wlcore/spi.c
@@ -70,16 +70,30 @@
 #define WSPI_MAX_CHUNK_SIZE4092

 /*
- * only support SPI for 12xx - this code should be reworked when 18xx
- * support is introduced
+ * wl18xx driver aggregation buffer size is (13 * PAGE_SIZE) compared 
+ to
+ * (4 * PAGE_SIZE) for wl12xx, so use the larger buffer needed for 
+ wl18xx
  */
-#define SPI_AGGR_BUFFER_SIZE (4 * PAGE_SIZE)
+#define SPI_AGGR_BUFFER_SIZE (13 * PAGE_SIZE)

 /* Maximum number of SPI write chunks */  #define WSPI_MAX_NUM_OF_CHUNKS \
((SPI_AGGR_BUFFER_SIZE / WSPI_MAX_CHUNK_SIZE) + 1)


+struct wilink_familiy_data {
+   char name[8];
+};
+
+const struct wilink_familiy_data *wilink_data;
+
+static const struct wilink_familiy_data wl18xx_data = {
+   .name = "wl18xx",
+};
+
+static const struct wilink_familiy_data wl12xx_data = {
+   .name = "wl12xx",
+};
+
 struct wl12xx_spi_glue {
struct device *dev;
struct platform_device *core;
@@ -119,6 +133,7 @@ static void wl12xx_spi_init(struct device *child)
struct wl12xx_spi_glue *glue = dev_get_drvdata(child->parent);
struct spi_transfer t;
struct spi_message m;
+

RE: [PATCH RESEND] iwlwifi, Do not implement thermal zone unless ucode is loaded

2016-07-17 Thread Grumbach, Emmanuel 
> On 07/15/2016 07:25 AM, Stanislaw Gruszka wrote:
> > On Thu, Jul 14, 2016 at 09:44:22AM +, Grumbach, Emmanuel wrote:
> >>> If I understad correctly this error happen 100% of the time, not
> >>> only during init. Hence seems there is an issue here, i.e. cur_ucode
> >>> is not marked correctly as IWL_UCODE_REGULAR or
> iwl_mvm_get_temp()
> >>> fail 100% of the time (iwl_mvm_is_tt_in_fw() incorrecly return true on
> Prarit device ? ).
> >>
> >> Cur_ucode will not be IWL_UCODE_REGULAR until you load the firmware
> >> which will happen upon ifup.
> >
> > Then creating thermal_device on ifup looks more reasonable to me.
> > Otherwise we can create device that can be non-functional virtually
> > forever, i.e. when soft RFKILL is enabled. However I admit that
> > creating thermal_device when HW is detected has some advantages too.
> 
> That's my plan right now.  Unfortunately something else in the kernel seems
> recently broken and is preventing me from testing.  I will get back to this
> early next week.
> 

But we already said that this won't work since you may have the device enabled 
upon boot and then disabled. So unless you unregister the thermal zone 
subsystem upon wifi disable, you won't solve the problem. Kalle and Luca 
already refused that solution.

I glanced (again) at the thermal zone API and since it allows to return an int, 
the subsystem itself should handle the failures and / or the userspace 
problems. The API itself is awful, it has no documentation whatsoever, even not 
variable names, but only types... You can't really blame the subsystem users to 
assume that a method that can return an int can't fail where the out values is 
passed by a pointer. Of course, you have to guess that this is the expected 
behavior, since you don't have any hint about the meaning of the parameters.
I think that the right place to "fix" this problem is to fix the subsystem. 
This way, you will fix it for iwlwifi and for any (future) other users that may 
fall into the trap opened by the API itself.
--
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