Re: [PATCH] brcmsmac: Fix build dep on LEDS_CLASS

[Arend van Spriel]

On 11/19/2013 12:32 AM, Borislav Petkov wrote:

On Mon, Nov 18, 2013 at 11:19:08PM +0100, Arend van Spriel wrote:

what about:

config BRCMSMAC
 tristate "Broadcom IEEE802.11n PCIe SoftMAC WLAN driver"
 depends on MAC80211
 depends on BCMA_POSSIBLE
+   select LEDS_CLASS if BCMA_DRIVER_GPIO
select BCMA


I know, nice and short but too good to be true. LEDS_CLASS needs to pull
in NEW_LEDS unfortunately:

drivers/built-in.o: In function `set_brightness_delayed':
led-class.c:(.text+0x4596e5): undefined reference to `led_stop_software_blink'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598db): undefined reference to `leds_list_lock'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598e7): undefined reference to `leds_list'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598f3): undefined reference to `leds_list'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598fa): undefined reference to `leds_list_lock'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x459901): undefined reference to `leds_list'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599a8): undefined reference to `led_stop_software_blink'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599b2): undefined reference to `led_set_brightness'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599c2): undefined reference to `leds_list_lock'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599d6): undefined reference to `leds_list_lock'
make: *** [vmlinux] Error 1

What works, instead, is below. I think my "depends" solution from
earlier takes care of this without you having to select other stuff
explicitly but in the end of the day, I don't really care all that much
which one you guys take.


The problem with 'select' is indeed that you need to cover all 
dependencies. It looks fine to me so why don't you just submit this to 
John Linville (and Cc: linux-wirel...@vger.kernel.org).


Regards,
Arend


--
diff --git a/drivers/net/wireless/brcm80211/Kconfig 
b/drivers/net/wireless/brcm80211/Kconfig
index b00a7e92225f..54e36fcb3954 100644
--- a/drivers/net/wireless/brcm80211/Kconfig
+++ b/drivers/net/wireless/brcm80211/Kconfig
@@ -5,6 +5,8 @@ config BRCMSMAC
 tristate "Broadcom IEEE802.11n PCIe SoftMAC WLAN driver"
 depends on MAC80211
 depends on BCMA
+   select NEW_LEDS if BCMA_DRIVER_GPIO
+   select LEDS_CLASS if BCMA_DRIVER_GPIO
 select BRCMUTIL
 select FW_LOADER
 select CRC_CCITT




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcmsmac: Fix build dep on LEDS_CLASS

[Arend van Spriel]

On 11/19/2013 12:32 AM, Borislav Petkov wrote:

On Mon, Nov 18, 2013 at 11:19:08PM +0100, Arend van Spriel wrote:

what about:

config BRCMSMAC
 tristate Broadcom IEEE802.11n PCIe SoftMAC WLAN driver
 depends on MAC80211
 depends on BCMA_POSSIBLE
+   select LEDS_CLASS if BCMA_DRIVER_GPIO
select BCMA


I know, nice and short but too good to be true. LEDS_CLASS needs to pull
in NEW_LEDS unfortunately:

drivers/built-in.o: In function `set_brightness_delayed':
led-class.c:(.text+0x4596e5): undefined reference to `led_stop_software_blink'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598db): undefined reference to `leds_list_lock'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598e7): undefined reference to `leds_list'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598f3): undefined reference to `leds_list'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x4598fa): undefined reference to `leds_list_lock'
drivers/built-in.o: In function `led_classdev_register':
(.text+0x459901): undefined reference to `leds_list'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599a8): undefined reference to `led_stop_software_blink'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599b2): undefined reference to `led_set_brightness'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599c2): undefined reference to `leds_list_lock'
drivers/built-in.o: In function `led_classdev_unregister':
(.text+0x4599d6): undefined reference to `leds_list_lock'
make: *** [vmlinux] Error 1

What works, instead, is below. I think my depends solution from
earlier takes care of this without you having to select other stuff
explicitly but in the end of the day, I don't really care all that much
which one you guys take.


The problem with 'select' is indeed that you need to cover all 
dependencies. It looks fine to me so why don't you just submit this to 
John Linville (and Cc: linux-wirel...@vger.kernel.org).


Regards,
Arend


--
diff --git a/drivers/net/wireless/brcm80211/Kconfig 
b/drivers/net/wireless/brcm80211/Kconfig
index b00a7e92225f..54e36fcb3954 100644
--- a/drivers/net/wireless/brcm80211/Kconfig
+++ b/drivers/net/wireless/brcm80211/Kconfig
@@ -5,6 +5,8 @@ config BRCMSMAC
 tristate Broadcom IEEE802.11n PCIe SoftMAC WLAN driver
 depends on MAC80211
 depends on BCMA
+   select NEW_LEDS if BCMA_DRIVER_GPIO
+   select LEDS_CLASS if BCMA_DRIVER_GPIO
 select BRCMUTIL
 select FW_LOADER
 select CRC_CCITT




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcmsmac: Fix build dep on LEDS_CLASS

[Arend van Spriel]

On 11/18/2013 09:40 PM, Borislav Petkov wrote:

On Mon, Nov 18, 2013 at 02:32:50PM +0100, Borislav Petkov wrote:

On Mon, Nov 18, 2013 at 12:58:58PM +0100, Rafał Miłecki wrote:

Borislav: I think I didn't get your original patch.


Forget it, I'll send a better one later.


Ok, let's try another one. I've done it with depends but we
probably could select LEDS_CLASS in BRCMSMAC_LED as it is required
functionality...


what about:

config BRCMSMAC
tristate "Broadcom IEEE802.11n PCIe SoftMAC WLAN driver"
depends on MAC80211
depends on BCMA_POSSIBLE
+   select LEDS_CLASS if BCMA_DRIVER_GPIO
select BCMA

Regards,
Arend


---
From: Borislav Petkov 
Subject: [PATCH -v2] brcmsmac: Fix build dep on LEDS_CLASS

When building randconfigs with CONFIG_BCMA_DRIVER_GPIO=y, I get

drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x351aca): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x351c65): undefined reference to `led_classdev_register'

during final linking stage because brcmsmac/led.c needs LEDS_CLASS for
registering/deregistering the led device. Add a promptless Kconfig
symbol which takes care of that dependency.

Cc: "Rafał Miłecki" 
Cc: 
Signed-off-by: Borislav Petkov 
---
  drivers/net/wireless/brcm80211/Kconfig   | 4 
  drivers/net/wireless/brcm80211/brcmsmac/Makefile | 2 +-
  drivers/net/wireless/brcm80211/brcmsmac/led.h| 2 +-
  3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/Kconfig 
b/drivers/net/wireless/brcm80211/Kconfig
index b00a7e92225f..c9434b7c7b9b 100644
--- a/drivers/net/wireless/brcm80211/Kconfig
+++ b/drivers/net/wireless/brcm80211/Kconfig
@@ -16,6 +16,10 @@ config BRCMSMAC
  be available if you select BCMA_DRIVER_GPIO. If you choose to build a
  module, the driver will be called brcmsmac.ko.

+config BRCMSMAC_LED
+   def_bool y
+   depends on BRCMSMAC && BCMA_DRIVER_GPIO && LEDS_CLASS
+
  config BRCMFMAC
tristate "Broadcom IEEE802.11n embedded FullMAC WLAN driver"
depends on CFG80211
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/Makefile 
b/drivers/net/wireless/brcm80211/brcmsmac/Makefile
index 32464acccd90..9ec2c8b2f26c 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/Makefile
+++ b/drivers/net/wireless/brcm80211/brcmsmac/Makefile
@@ -43,6 +43,6 @@ brcmsmac-y := \
brcms_trace_events.o \
debug.o

-brcmsmac-$(CONFIG_BCMA_DRIVER_GPIO) += led.o
+brcmsmac-$(CONFIG_BRCMSMAC_LED) += led.o

  obj-$(CONFIG_BRCMSMAC)+= brcmsmac.o
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/led.h 
b/drivers/net/wireless/brcm80211/brcmsmac/led.h
index 17a0b1f5dbcf..b914466e687b 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/led.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/led.h
@@ -22,7 +22,7 @@ struct brcms_led {
bool active_low;
  };

-#ifdef CONFIG_BCMA_DRIVER_GPIO
+#ifdef CONFIG_BRCMSMAC_LED
  void brcms_led_unregister(struct brcms_info *wl);
  int brcms_led_register(struct brcms_info *wl);
  #else




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcmsmac: Fix build dep on LEDS_CLASS

[Arend van Spriel]

On 11/18/2013 09:40 PM, Borislav Petkov wrote:

On Mon, Nov 18, 2013 at 02:32:50PM +0100, Borislav Petkov wrote:

On Mon, Nov 18, 2013 at 12:58:58PM +0100, Rafał Miłecki wrote:

Borislav: I think I didn't get your original patch.


Forget it, I'll send a better one later.


Ok, let's try another one. I've done it with depends but we
probably could select LEDS_CLASS in BRCMSMAC_LED as it is required
functionality...


what about:

config BRCMSMAC
tristate Broadcom IEEE802.11n PCIe SoftMAC WLAN driver
depends on MAC80211
depends on BCMA_POSSIBLE
+   select LEDS_CLASS if BCMA_DRIVER_GPIO
select BCMA

Regards,
Arend


---
From: Borislav Petkov b...@suse.de
Subject: [PATCH -v2] brcmsmac: Fix build dep on LEDS_CLASS

When building randconfigs with CONFIG_BCMA_DRIVER_GPIO=y, I get

drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x351aca): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x351c65): undefined reference to `led_classdev_register'

during final linking stage because brcmsmac/led.c needs LEDS_CLASS for
registering/deregistering the led device. Add a promptless Kconfig
symbol which takes care of that dependency.

Cc: Rafał Miłecki zaj...@gmail.com
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Borislav Petkov b...@suse.de
---
  drivers/net/wireless/brcm80211/Kconfig   | 4 
  drivers/net/wireless/brcm80211/brcmsmac/Makefile | 2 +-
  drivers/net/wireless/brcm80211/brcmsmac/led.h| 2 +-
  3 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/drivers/net/wireless/brcm80211/Kconfig 
b/drivers/net/wireless/brcm80211/Kconfig
index b00a7e92225f..c9434b7c7b9b 100644
--- a/drivers/net/wireless/brcm80211/Kconfig
+++ b/drivers/net/wireless/brcm80211/Kconfig
@@ -16,6 +16,10 @@ config BRCMSMAC
  be available if you select BCMA_DRIVER_GPIO. If you choose to build a
  module, the driver will be called brcmsmac.ko.

+config BRCMSMAC_LED
+   def_bool y
+   depends on BRCMSMAC  BCMA_DRIVER_GPIO  LEDS_CLASS
+
  config BRCMFMAC
tristate Broadcom IEEE802.11n embedded FullMAC WLAN driver
depends on CFG80211
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/Makefile 
b/drivers/net/wireless/brcm80211/brcmsmac/Makefile
index 32464acccd90..9ec2c8b2f26c 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/Makefile
+++ b/drivers/net/wireless/brcm80211/brcmsmac/Makefile
@@ -43,6 +43,6 @@ brcmsmac-y := \
brcms_trace_events.o \
debug.o

-brcmsmac-$(CONFIG_BCMA_DRIVER_GPIO) += led.o
+brcmsmac-$(CONFIG_BRCMSMAC_LED) += led.o

  obj-$(CONFIG_BRCMSMAC)+= brcmsmac.o
diff --git a/drivers/net/wireless/brcm80211/brcmsmac/led.h 
b/drivers/net/wireless/brcm80211/brcmsmac/led.h
index 17a0b1f5dbcf..b914466e687b 100644
--- a/drivers/net/wireless/brcm80211/brcmsmac/led.h
+++ b/drivers/net/wireless/brcm80211/brcmsmac/led.h
@@ -22,7 +22,7 @@ struct brcms_led {
bool active_low;
  };

-#ifdef CONFIG_BCMA_DRIVER_GPIO
+#ifdef CONFIG_BRCMSMAC_LED
  void brcms_led_unregister(struct brcms_info *wl);
  int brcms_led_register(struct brcms_info *wl);
  #else




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcmsmac: Fix build dep on LEDS_CLASS

[Arend van Spriel]

On 11/17/13 14:37, Borislav Petkov wrote:

From: Borislav Petkov

When building randconfigs with CONFIG_BCMA_DRIVER_GPIO=y, I get

drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x351aca): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x351c65): undefined reference to `led_classdev_register'

during the final linking stage because brcmsmac/led.c needs LEDS_CLASS
for reg/dereg. Fix that.


Wouldn't it be better to fix it in brcmsmac.

Gr AvS


Cc: "Rafał Miłecki"
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Borislav Petkov
---

I'm attaching the .config in question.

  drivers/bcma/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index 7c081b38ef3e..74dba9ca1413 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -74,7 +74,7 @@ config BCMA_DRIVER_GMAC_CMN

  config BCMA_DRIVER_GPIO
bool "BCMA GPIO driver"
-   depends on BCMA&&  GPIOLIB
+   depends on BCMA&&  GPIOLIB&&  LEDS_CLASS
help
  Driver to provide access to the GPIO pins of the bcma bus.




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] brcmsmac: Fix build dep on LEDS_CLASS

[Arend van Spriel]

On 11/17/13 14:37, Borislav Petkov wrote:

From: Borislav Petkovb...@suse.de

When building randconfigs with CONFIG_BCMA_DRIVER_GPIO=y, I get

drivers/built-in.o: In function `brcms_led_unregister':
(.text+0x351aca): undefined reference to `led_classdev_unregister'
drivers/built-in.o: In function `brcms_led_register':
(.text+0x351c65): undefined reference to `led_classdev_register'

during the final linking stage because brcmsmac/led.c needs LEDS_CLASS
for reg/dereg. Fix that.


Wouldn't it be better to fix it in brcmsmac.

Gr AvS


Cc: Rafał Miłeckizaj...@gmail.com
Cc: linux-wirel...@vger.kernel.org
Signed-off-by: Borislav Petkovb...@suse.de
---

I'm attaching the .config in question.

  drivers/bcma/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/bcma/Kconfig b/drivers/bcma/Kconfig
index 7c081b38ef3e..74dba9ca1413 100644
--- a/drivers/bcma/Kconfig
+++ b/drivers/bcma/Kconfig
@@ -74,7 +74,7 @@ config BCMA_DRIVER_GMAC_CMN

  config BCMA_DRIVER_GPIO
bool BCMA GPIO driver
-   depends on BCMA  GPIOLIB
+   depends on BCMA  GPIOLIB  LEDS_CLASS
help
  Driver to provide access to the GPIO pins of the bcma bus.




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [RESEND][TRIVIAL] treewide: fix occurrences of "the the "

[Arend van Spriel]

On 11/12/2013 06:10 AM, Michael Opdenacker wrote:

Fix all occurrences of "the the " in the source code,
comments and documentation.

The replacement couldn't be automated because sometimes
the first "the" was meant to be another word.

Example: "according the the"
meaning: "according to the"

Note that I sometimes took the opportunity to fix
other spelling issues or typos in the same sentences.
I also fixed a few checkpatch errors in the same
lines.

This is an update to the patch sent on Sep. 12, 2013


Better put this kind of info below the signed-off-by line. Or even 
better use the message-id of that patch in the 'In-Reply-To:' field that 
git-send-email prompts for.


For driver change mentioned below:
Acked-by: Arend van Spriel 

Signed-off-by: Michael Opdenacker 

---
so here: 'This is an update to the patch sent on Sep. 12, 2013'

---
  drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] [RESEND][TRIVIAL] treewide: fix occurrences of the the

[Arend van Spriel]

On 11/12/2013 06:10 AM, Michael Opdenacker wrote:

Fix all occurrences of the the  in the source code,
comments and documentation.

The replacement couldn't be automated because sometimes
the first the was meant to be another word.

Example: according the the
meaning: according to the

Note that I sometimes took the opportunity to fix
other spelling issues or typos in the same sentences.
I also fixed a few checkpatch errors in the same
lines.

This is an update to the patch sent on Sep. 12, 2013


Better put this kind of info below the signed-off-by line. Or even 
better use the message-id of that patch in the 'In-Reply-To:' field that 
git-send-email prompts for.


For driver change mentioned below:
Acked-by: Arend van Spriel ar...@broadcom.com

Signed-off-by: Michael Opdenacker michael.opdenac...@free-electrons.com

---
so here: 'This is an update to the patch sent on Sep. 12, 2013'

---
  drivers/net/wireless/brcm80211/brcmsmac/main.c | 2 +-



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Arend van Spriel]

On 11/01/2013 08:45 PM, Matt Porter wrote:

Add a binding that describes the Broadcom Kona USB2 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter 
---
  .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt | 15 +++
  1 file changed, 15 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt 
b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
new file mode 100644
index 000..db309e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - regs: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+   usbphy: usbphy@3f13 {
+   compatible = "brcm,kona-usb2-phy";
+   reg = <0x3f13 0x28>;


I expect 'regs' iso 'reg' in this example.

Regards,
Arend


+   #phy-cells = <0>;
+   };




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 7/9] phy: add Broadcom Kona USB2 PHY DT binding

[Arend van Spriel]

On 11/01/2013 08:45 PM, Matt Porter wrote:

Add a binding that describes the Broadcom Kona USB2 PHY found
on the BCM281xx family of SoCs.

Signed-off-by: Matt Porter matt.por...@linaro.org
---
  .../devicetree/bindings/phy/bcm-kona-usb2-phy.txt | 15 +++
  1 file changed, 15 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt

diff --git a/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt 
b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
new file mode 100644
index 000..db309e2
--- /dev/null
+++ b/Documentation/devicetree/bindings/phy/bcm-kona-usb2-phy.txt
@@ -0,0 +1,15 @@
+BROADCOM KONA USB2 PHY
+
+Required properties:
+ - compatible: brcm,kona-usb2-phy
+ - regs: offset and length of the PHY registers
+ - #phy-cells: must be 0
+Refer to phy/phy-bindings.txt for the generic PHY binding properties
+
+Example:
+
+   usbphy: usbphy@3f13 {
+   compatible = brcm,kona-usb2-phy;
+   reg = 0x3f13 0x28;


I expect 'regs' iso 'reg' in this example.

Regards,
Arend


+   #phy-cells = 0;
+   };




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: trace-cmd problem with FC19

[Arend van Spriel]

On 10/17/2013 11:11 PM, Bob Copeland wrote:

On Thu, Oct 17, 2013 at 04:56:56PM -0400, Steven Rostedt wrote:

Hmm, are you sure?

You may want to do both:

sudo trace-cmd -v
which trace-cmd


Aaargh, bullocks! My home dir is an NFS mount on FC19 x64 machine and it 
has a 32-bit trace-cmd installed in ~/bin. Sorry for the noise.



to see which version it is.


To clarify - I ran into the referenced issue using an older,
self-compiled version with a recent kernel.  The FC19 distro
version may be fine, for all I know.


Indeed saw your post googling for this error message, which is why I 
cloned trace-cmd repo.


Going to sit in a corner feeling stupid :-(

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: trace-cmd problem with FC19

[Arend van Spriel]

On 10/17/2013 11:11 PM, Bob Copeland wrote:

On Thu, Oct 17, 2013 at 04:56:56PM -0400, Steven Rostedt wrote:

Hmm, are you sure?

You may want to do both:

sudo trace-cmd -v
which trace-cmd


Aaargh, bullocks! My home dir is an NFS mount on FC19 x64 machine and it 
has a 32-bit trace-cmd installed in ~/bin. Sorry for the noise.



to see which version it is.


To clarify - I ran into the referenced issue using an older,
self-compiled version with a recent kernel.  The FC19 distro
version may be fine, for all I know.


Indeed saw your post googling for this error message, which is why I 
cloned trace-cmd repo.


Going to sit in a corner feeling stupid :-(

Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: trace-cmd problem with FC19

[Arend van Spriel]

On 10/17/13 20:41, Steven Rostedt wrote:

On Thu, 17 Oct 2013 14:08:08 +0200
"Arend van Spriel"  wrote:


Hi Steven,

When tracing I get these error messages and no trace data is recorded. I
also cloned the trace-cmd repo and tried that with the same result. I
think the kernel configuration looks ok, but adding it.

I use it almost daily on Ubuntu system, but trying Fedora for a change.
I do have a difference with kernel taint with my driver loaded:

Ubuntu  4096(OOT module loaded, ie. my driver)
Fedora  4098(OOT *and* forced module?)

'forced module' probably caused by:
[10808.074823] Request for unknown module key 'Fedora kernel signing
key: 8661dbf3061bfa70eb76d61691cec200318534b4' err -11

Would that explain my issue?

Regards,
Arend

---8<
$ sudo trace-cmd record -e brcmfmac:*
/sys/kernel/debug/tracing/events/brcmfmac/*/filter
Hit Ctrl^C to stop recording
^Ctrace-cmd: Interrupted system call
trace-cmd: Interrupted system call
  recorder error in splice inputrecorder error in splice input


I haven't seen this before.

Was the brcmfmac module the one that was forced loaded?

Does recording other traces work? Or is it only spicific to this module?


It seems a generic issue:

$ sudo trace-cmd record -e ext4:* ls
/sys/kernel/debug/tracing/events/ext4/*/filter
systemd-private-6pVB5L  systemd-private-KdpFqS  trace.dat.cpu0  trace.dat.cpu2
systemd-private-9hedRD  trace.dat   trace.dat.cpu1  trace.dat.cpu3
trace-cmd: Interrupted system call
  recorder error in splice input
trace-cmd: Interrupted system call
  recorder error in splice input
trace-cmd: Interrupted system call
  recorder error in splice input
trace-cmd: Interrupted system call
  recorder error in splice input
Kernel buffer statistics:
  Note: "entries" are the entries left in the kernel ring buffer and 
are not

recorded in the trace data. They should all be zero.

I got the modules properly signed so only OOT taint is set and it still 
does not work.


Regards,
Arend


-- Steve



trace-cmd: Interrupted system call
recorder error in splice input
trace-cmd: Interrupted system call
recorder error in splice input
Kernel buffer statistics:
Note: "entries" are the entries left in the kernel ring buffer and
are not
  recorded in the trace data. They should all be zero.







--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: trace-cmd problem with FC19

[Arend van Spriel]

On 10/17/13 20:41, Steven Rostedt wrote:

On Thu, 17 Oct 2013 14:08:08 +0200
Arend van Sprielar...@broadcom.com  wrote:


Hi Steven,

When tracing I get these error messages and no trace data is recorded. I
also cloned the trace-cmd repo and tried that with the same result. I
think the kernel configuration looks ok, but adding it.

I use it almost daily on Ubuntu system, but trying Fedora for a change.
I do have a difference with kernel taint with my driver loaded:

Ubuntu  4096(OOT module loaded, ie. my driver)
Fedora  4098(OOT *and* forced module?)

'forced module' probably caused by:
[10808.074823] Request for unknown module key 'Fedora kernel signing
key: 8661dbf3061bfa70eb76d61691cec200318534b4' err -11

Would that explain my issue?

Regards,
Arend

---8
$ sudo trace-cmd record -e brcmfmac:*
/sys/kernel/debug/tracing/events/brcmfmac/*/filter
Hit Ctrl^C to stop recording
^Ctrace-cmd: Interrupted system call
trace-cmd: Interrupted system call
  recorder error in splice inputrecorder error in splice input


I haven't seen this before.

Was the brcmfmac module the one that was forced loaded?

Does recording other traces work? Or is it only spicific to this module?


It seems a generic issue:

$ sudo trace-cmd record -e ext4:* ls
/sys/kernel/debug/tracing/events/ext4/*/filter
systemd-private-6pVB5L  systemd-private-KdpFqS  trace.dat.cpu0  trace.dat.cpu2
systemd-private-9hedRD  trace.dat   trace.dat.cpu1  trace.dat.cpu3
trace-cmd: Interrupted system call
  recorder error in splice input
trace-cmd: Interrupted system call
  recorder error in splice input
trace-cmd: Interrupted system call
  recorder error in splice input
trace-cmd: Interrupted system call
  recorder error in splice input
Kernel buffer statistics:
  Note: entries are the entries left in the kernel ring buffer and 
are not

recorded in the trace data. They should all be zero.

I got the modules properly signed so only OOT taint is set and it still 
does not work.


Regards,
Arend


-- Steve



trace-cmd: Interrupted system call
recorder error in splice input
trace-cmd: Interrupted system call
recorder error in splice input
Kernel buffer statistics:
Note: entries are the entries left in the kernel ring buffer and
are not
  recorded in the trace data. They should all be zero.







--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 10/01/2013 01:29 PM, Luca Coelho wrote:

Hi,

On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote:

On 10/01/2013 11:53 AM, Roger Quadros wrote:

On 10/01/2013 12:49 PM, Roger Quadros wrote:

Hi Arend,

On 10/01/2013 11:05 AM, Arend van Spriel wrote:

On 07/19/2013 12:57 PM, Arend van Spriel wrote:

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.


That was what I was looking for. Thanks!


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a couple 
of pandaboards used as test setup. These have an SDIO adapter hooked up to 
expansion connector A using MMC2. I have attached the patch file (just ignore 
platform_data stuff). Now on one board it works, but not for the other. I 
suspect a board issue so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you 
isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi
thing).



OK, just realized that the expansion connector uses different pads for MMC2. 
However, you still
need to make sure that the other pins (connected to on board WLAN chip) are not 
muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I
am not mistaken(?). Attached are the dmesg logs of the two boards.


I sent 2 patch series to add DT support for the on-board WLAN, but they
were not applied, since there were some comments that required changes.
I really don't have the time to revisit them now that I'm not with TI
anymore, so I'm hoping someone else will pick them up at some point.


I found this one in my email archive:

[PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp

Guess that is what you are referring to, right?

Gr. AvS


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 10/01/2013 03:19 PM, Balaji T K wrote:

Hi Roger,

It has been a while, but I would like to pickup this thread. We
have a couple of pandaboards used as test setup. These have an
SDIO adapter hooked up to expansion connector A using MMC2. I have
attached the patch file (just ignore platform_data stuff). Now on
one board it works, but not for the other. I suspect a board issue
so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how
do you isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the
TiWi thing).



OK, just realized that the expansion connector uses different pads
for MMC2. However, you still
need to make sure that the other pins (connected to on board WLAN
chip) are not muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5
if I am not mistaken(?). Attached are the dmesg logs of the two boards.


Right. WLAN is supposed to use MMC5. But if you don't have Luca's
patches, can you please ensure that those pins are muxed either as
safe mode
or as MMC5? Default seems to be safe mode, but you should cross check.

Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP
Shouldn't it be PIN_OUTPUT?

Still I have no clue why it works on 4430 and not on 4460. Are you
using the same bootloader image on both boards?


if you are using vaux1, can you check the voltage levels,

 From dmesg you attached,
vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460

4430
[2.425750] VAUX1_6030: 1000 <--> 3000 mV at 1800 mV

4460
[2.244262] VAUX1_6030: 1000 <--> 3000 mV at 2800 mV


Nice catch. Not sure whether this is an issue, but worth looking into.


Can you also check with MMC_DEBUG enabled for any clues.


building


cheers,
-roger
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] net:drivers/net: Miscellaneous conversions to ETH_ALEN

[Arend van Spriel]

On 10/02/2013 04:04 AM, Joe Perches wrote:

Convert the memset/memcpy uses of 6 to ETH_ALEN
where appropriate.

Also convert some struct definitions and u8 array
declarations of [6] to ETH_ALEN.


For brcmsmac

Acked-by: Arend van Spriel 

Signed-off-by: Joe Perches 
---
  drivers/net/wireless/brcm80211/brcmsmac/main.c |  6 +-



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH net-next] net:drivers/net: Miscellaneous conversions to ETH_ALEN

[Arend van Spriel]

On 10/02/2013 04:04 AM, Joe Perches wrote:

Convert the memset/memcpy uses of 6 to ETH_ALEN
where appropriate.

Also convert some struct definitions and u8 array
declarations of [6] to ETH_ALEN.


For brcmsmac

Acked-by: Arend van Spriel ar...@broadcom.com

Signed-off-by: Joe Perches j...@perches.com
---
  drivers/net/wireless/brcm80211/brcmsmac/main.c |  6 +-



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 10/01/2013 03:19 PM, Balaji T K wrote:

Hi Roger,

It has been a while, but I would like to pickup this thread. We
have a couple of pandaboards used as test setup. These have an
SDIO adapter hooked up to expansion connector A using MMC2. I have
attached the patch file (just ignore platform_data stuff). Now on
one board it works, but not for the other. I suspect a board issue
so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how
do you isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the
TiWi thing).



OK, just realized that the expansion connector uses different pads
for MMC2. However, you still
need to make sure that the other pins (connected to on board WLAN
chip) are not muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5
if I am not mistaken(?). Attached are the dmesg logs of the two boards.


Right. WLAN is supposed to use MMC5. But if you don't have Luca's
patches, can you please ensure that those pins are muxed either as
safe mode
or as MMC5? Default seems to be safe mode, but you should cross check.

Also in your patches you have set mmc2-clk to PIN_INPUT_PULLUP
Shouldn't it be PIN_OUTPUT?

Still I have no clue why it works on 4430 and not on 4460. Are you
using the same bootloader image on both boards?


if you are using vaux1, can you check the voltage levels,

 From dmesg you attached,
vaux1 is set to 1.8V on omap4430 and to 2.8V on OMAP4460

4430
[2.425750] VAUX1_6030: 1000 -- 3000 mV at 1800 mV

4460
[2.244262] VAUX1_6030: 1000 -- 3000 mV at 2800 mV


Nice catch. Not sure whether this is an issue, but worth looking into.


Can you also check with MMC_DEBUG enabled for any clues.


building


cheers,
-roger
--
To unsubscribe from this list: send the line unsubscribe linux-omap in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 10/01/2013 01:29 PM, Luca Coelho wrote:

Hi,

On Tue, 2013-10-01 at 12:53 +0200, Arend van Spriel wrote:

On 10/01/2013 11:53 AM, Roger Quadros wrote:

On 10/01/2013 12:49 PM, Roger Quadros wrote:

Hi Arend,

On 10/01/2013 11:05 AM, Arend van Spriel wrote:

On 07/19/2013 12:57 PM, Arend van Spriel wrote:

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.


That was what I was looking for. Thanks!


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a couple 
of pandaboards used as test setup. These have an SDIO adapter hooked up to 
expansion connector A using MMC2. I have attached the patch file (just ignore 
platform_data stuff). Now on one board it works, but not for the other. I 
suspect a board issue so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you 
isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi
thing).



OK, just realized that the expansion connector uses different pads for MMC2. 
However, you still
need to make sure that the other pins (connected to on board WLAN chip) are not 
muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I
am not mistaken(?). Attached are the dmesg logs of the two boards.


I sent 2 patch series to add DT support for the on-board WLAN, but they
were not applied, since there were some comments that required changes.
I really don't have the time to revisit them now that I'm not with TI
anymore, so I'm hoping someone else will pick them up at some point.


I found this one in my email archive:

[PATCH v2 0/4] ARM: dts: add WiLink support to panda and omap4-sdp

Guess that is what you are referring to, right?

Gr. AvS


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 10/01/2013 11:53 AM, Roger Quadros wrote:

On 10/01/2013 12:49 PM, Roger Quadros wrote:

Hi Arend,

On 10/01/2013 11:05 AM, Arend van Spriel wrote:

On 07/19/2013 12:57 PM, Arend van Spriel wrote:

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.


That was what I was looking for. Thanks!


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a couple 
of pandaboards used as test setup. These have an SDIO adapter hooked up to 
expansion connector A using MMC2. I have attached the patch file (just ignore 
platform_data stuff). Now on one board it works, but not for the other. I 
suspect a board issue so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you 
isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi 
thing).




OK, just realized that the expansion connector uses different pads for MMC2. 
However, you still
need to make sure that the other pins (connected to on board WLAN chip) are not 
muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I 
am not mistaken(?). Attached are the dmesg logs of the two boards.


Regards,
Arend

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.11.0-wl-27553-g4a20162 (arend@arend-ubuntu-1) 
(gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #5 SMP Mon Sep 23 10:42:07 
CEST 2013
[0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 
PandaBoard
[0.00] cma: CMA: reserved 16 MiB at ae80
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] On node 0 totalpages: 261888
[0.00] free_area_init_node: node 0, pgdat c08835c0, node_mem_map 
c0ded000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 528 pages used for memmap
[0.00]   HighMem zone: 67328 pages, LIFO batch:15
[0.00] OMAP4430 ES2.1
[0.00] PERCPU: Embedded 9 pages/cpu @c1607000 s14208 r8192 d14464 u36864
[0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260368
[0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait 
console=ttyO2,115200
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1007680K/1047552K available (5750K kernel code, 614K 
rwdata, 1952K rodata, 381K init, 5522K bss, 39872K reserved, 269312K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc078d9c8   (7703

using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 07/19/2013 12:57 PM, Arend van Spriel wrote:

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.


That was what I was looking for. Thanks!


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a 
couple of pandaboards used as test setup. These have an SDIO adapter 
hooked up to expansion connector A using MMC2. I have attached the patch 
file (just ignore platform_data stuff). Now on one board it works, but 
not for the other. I suspect a board issue so listing the two types that 
we use:


PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.

Regards,
Arend


NOTE: omap4_pmx_wkup starts at a different address. Those are for
wakeup domain
control registers.


Will keep that in mind.

Regards,
Arend



>From 4a20162935b27e23ec7ddc818c9fe6b451c1a968 Mon Sep 17 00:00:00 2001
From: Arend van Spriel 
Date: Thu, 22 Aug 2013 12:29:23 +0200
Subject: [PATCH] brcmfmac: add device tree support for panda board

In linux mainline the pandaboard specific code moved to using
the device tree. Changing our internal patches to get platform
specific info from the device tree.

Signed-off-by: Arend van Spriel 
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   20 +++-
 arch/arm/mach-omap2/devices.c |   36 -
 2 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..6ebeb8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -226,6 +226,22 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
>;
};
+   mmc2_brcmf_en: pinmux_mmc2_brcmf_en {
+   pinctrl-single,pins = <
+   0x92 (PIN_OUTPUT | MUX_MODE3)   /* brcmf-power 
*/
+   >;
+   };
+   mmc2_pins: pinmux_mmc2_pins {
+   pinctrl-single,pins = <
+   0x44 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-cmd */
+   0x42 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-clk */
+   0x00 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-dat 0-3 
*/
+   0x02 (MUX_MODE1 | PIN_INPUT_PULLUP)
+   0x04 (MUX_MODE1 | PIN_INPUT_PULLUP)
+   0x06 (MUX_MODE1 | PIN_INPUT_PULLUP)
+   0x9a (MUX_MODE3 | PIN_INPUT_PULLDOWN)   /* oob-irq */
+   >;
+   };
 };
 
 _pmx_wkup {
@@ -302,7 +318,9 @@
 };
 
  {
-   status = "disabled";
+   vmmc-supply = <>;
+   bus-width = <4>;
+   non-removable;
 };
 
  {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..7a47535 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -21,7 +21,7 @@
 #include 
 #include 
 #include 
-
+#include 
 #include 
 #include 
 
@@ -547,6 +547,39 @@ static inline void omap_init_wl12xx_of(void)
 }
 #endif
 
+#define GPIO_BRCMF_SDIO_PWR134
+#define GPIO_BRCMF_SDIO_OOB138
+static struct brcmfmac_sdio_platform_data brcmfmac_sdio_pdata;
+
+static struct platform_device brcmf_sdio_device = {
+   .name   = BRCMFMAC_SDIO_PDATA_NAME,
+   .id = PLATFORM_DEVID_NONE,
+   .dev.platform_data  = _sdio_pdata
+};
+
+static struct gpio brcmf_sdio_gpios[] __initdata = {
+   { GPIO_BRCMF_SDIO_PWR,  GPIOF_OUT_INIT_HIGH,"brcmf_sdio_pwr"},
+   { GPIO_BRCMF_SDIO_OOB,  GPIO

Re: using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 10/01/2013 11:53 AM, Roger Quadros wrote:

On 10/01/2013 12:49 PM, Roger Quadros wrote:

Hi Arend,

On 10/01/2013 11:05 AM, Arend van Spriel wrote:

On 07/19/2013 12:57 PM, Arend van Spriel wrote:

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.


That was what I was looking for. Thanks!


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a couple 
of pandaboards used as test setup. These have an SDIO adapter hooked up to 
expansion connector A using MMC2. I have attached the patch file (just ignore 
platform_data stuff). Now on one board it works, but not for the other. I 
suspect a board issue so listing the two types that we use:

PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.


Does your PandaboardES have the WLAN chip (U4) mounted? If yes, how do you 
isolate
it from your external SDIO adapter?


On my 4460 board in front of me U4 is not populated, but U3 is (the TiWi 
thing).




OK, just realized that the expansion connector uses different pads for MMC2. 
However, you still
need to make sure that the other pins (connected to on board WLAN chip) are not 
muxed as MMC2.


I think Luciano added DT patches for on-board WLAN and it uses MMC5 if I 
am not mistaken(?). Attached are the dmesg logs of the two boards.


Regards,
Arend

[0.00] Booting Linux on physical CPU 0x0
[0.00] Linux version 3.11.0-wl-27553-g4a20162 (arend@arend-ubuntu-1) 
(gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) ) #5 SMP Mon Sep 23 10:42:07 
CEST 2013
[0.00] CPU: ARMv7 Processor [411fc092] revision 2 (ARMv7), cr=10c53c7d
[0.00] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing 
instruction cache
[0.00] Machine: Generic OMAP4 (Flattened Device Tree), model: TI OMAP4 
PandaBoard
[0.00] cma: CMA: reserved 16 MiB at ae80
[0.00] Memory policy: ECC disabled, Data cache writealloc
[0.00] On node 0 totalpages: 261888
[0.00] free_area_init_node: node 0, pgdat c08835c0, node_mem_map 
c0ded000
[0.00]   Normal zone: 1520 pages used for memmap
[0.00]   Normal zone: 0 pages reserved
[0.00]   Normal zone: 194560 pages, LIFO batch:31
[0.00]   HighMem zone: 528 pages used for memmap
[0.00]   HighMem zone: 67328 pages, LIFO batch:15
[0.00] OMAP4430 ES2.1
[0.00] PERCPU: Embedded 9 pages/cpu @c1607000 s14208 r8192 d14464 u36864
[0.00] pcpu-alloc: s14208 r8192 d14464 u36864 alloc=9*4096
[0.00] pcpu-alloc: [0] 0 [0] 1 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 260368
[0.00] Kernel command line: root=/dev/mmcblk0p2 rootwait 
console=ttyO2,115200
[0.00] PID hash table entries: 4096 (order: 2, 16384 bytes)
[0.00] Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
[0.00] Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
[0.00] Memory: 1007680K/1047552K available (5750K kernel code, 614K 
rwdata, 1952K rodata, 381K init, 5522K bss, 39872K reserved, 269312K highmem)
[0.00] Virtual kernel memory layout:
[0.00] vector  : 0x - 0x1000   (   4 kB)
[0.00] fixmap  : 0xfff0 - 0xfffe   ( 896 kB)
[0.00] vmalloc : 0xf000 - 0xff00   ( 240 MB)
[0.00] lowmem  : 0xc000 - 0xef80   ( 760 MB)
[0.00] pkmap   : 0xbfe0 - 0xc000   (   2 MB)
[0.00] modules : 0xbf00 - 0xbfe0   (  14 MB)
[0.00]   .text : 0xc0008000 - 0xc078d9c8   (7703

using mmc2 on panda [was: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet]

[Arend van Spriel]

On 07/19/2013 12:57 PM, Arend van Spriel wrote:

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I
do have a question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP |
MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP |
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 |
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is
probably an explanation to it and it would help my understanding to
know where this difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address
0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h
for pmx_core registers.


That was what I was looking for. Thanks!


Hi Roger,

It has been a while, but I would like to pickup this thread. We have a 
couple of pandaboards used as test setup. These have an SDIO adapter 
hooked up to expansion connector A using MMC2. I have attached the patch 
file (just ignore platform_data stuff). Now on one board it works, but 
not for the other. I suspect a board issue so listing the two types that 
we use:


PandaBoard rev A2 (dmesg: OMAP4430 ES2.1): works
PandaBoardES rev B1 (dmesg: OMAP4460 ES1.1): nope

Any hints for me.

Regards,
Arend


NOTE: omap4_pmx_wkup starts at a different address. Those are for
wakeup domain
control registers.


Will keep that in mind.

Regards,
Arend



From 4a20162935b27e23ec7ddc818c9fe6b451c1a968 Mon Sep 17 00:00:00 2001
From: Arend van Spriel ar...@broadcom.com
Date: Thu, 22 Aug 2013 12:29:23 +0200
Subject: [PATCH] brcmfmac: add device tree support for panda board

In linux mainline the pandaboard specific code moved to using
the device tree. Changing our internal patches to get platform
specific info from the device tree.

Signed-off-by: Arend van Spriel ar...@broadcom.com
---
 arch/arm/boot/dts/omap4-panda-common.dtsi |   20 +++-
 arch/arm/mach-omap2/devices.c |   36 -
 2 files changed, 54 insertions(+), 2 deletions(-)

diff --git a/arch/arm/boot/dts/omap4-panda-common.dtsi 
b/arch/arm/boot/dts/omap4-panda-common.dtsi
index faa95b5..6ebeb8e 100644
--- a/arch/arm/boot/dts/omap4-panda-common.dtsi
+++ b/arch/arm/boot/dts/omap4-panda-common.dtsi
@@ -226,6 +226,22 @@
0xf0 (PIN_INPUT_PULLUP | MUX_MODE0) /* i2c4_sda */
;
};
+   mmc2_brcmf_en: pinmux_mmc2_brcmf_en {
+   pinctrl-single,pins = 
+   0x92 (PIN_OUTPUT | MUX_MODE3)   /* brcmf-power 
*/
+   ;
+   };
+   mmc2_pins: pinmux_mmc2_pins {
+   pinctrl-single,pins = 
+   0x44 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-cmd */
+   0x42 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-clk */
+   0x00 (MUX_MODE1 | PIN_INPUT_PULLUP) /* mmc2-dat 0-3 
*/
+   0x02 (MUX_MODE1 | PIN_INPUT_PULLUP)
+   0x04 (MUX_MODE1 | PIN_INPUT_PULLUP)
+   0x06 (MUX_MODE1 | PIN_INPUT_PULLUP)
+   0x9a (MUX_MODE3 | PIN_INPUT_PULLDOWN)   /* oob-irq */
+   ;
+   };
 };
 
 omap4_pmx_wkup {
@@ -302,7 +318,9 @@
 };
 
 mmc2 {
-   status = disabled;
+   vmmc-supply = vaux1;
+   bus-width = 4;
+   non-removable;
 };
 
 mmc3 {
diff --git a/arch/arm/mach-omap2/devices.c b/arch/arm/mach-omap2/devices.c
index 3c1279f..7a47535 100644
--- a/arch/arm/mach-omap2/devices.c
+++ b/arch/arm/mach-omap2/devices.c
@@ -21,7 +21,7 @@
 #include linux/platform_data/omap4-keypad.h
 #include linux/wl12xx.h
 #include linux/platform_data/mailbox-omap.h
-
+#include linux/platform_data/brcmfmac-sdio.h
 #include asm/mach-types.h
 #include asm/mach/map.h
 
@@ -547,6 +547,39 @@ static inline void omap_init_wl12xx_of(void)
 }
 #endif
 
+#define GPIO_BRCMF_SDIO_PWR134
+#define GPIO_BRCMF_SDIO_OOB138
+static struct brcmfmac_sdio_platform_data brcmfmac_sdio_pdata;
+
+static struct platform_device brcmf_sdio_device = {
+   .name   = BRCMFMAC_SDIO_PDATA_NAME,
+   .id = PLATFORM_DEVID_NONE,
+   .dev.platform_data  = brcmfmac_sdio_pdata
+};
+
+static struct

Re: [brcmfmac] BUG: unable to handle kernel paging request at ffffffff82196446

[Arend van Spriel]

On 09/23/2013 02:14 PM, Fengguang Wu wrote:

On Mon, Sep 16, 2013 at 11:15:53AM +0200, Arend van Spriel wrote:

On 09/02/2013 12:23 PM, Fengguang Wu wrote:

Greetings,

I got the below dmesg and the first bad commit is


Hi Fengguang,

I could not reproduce this issue. Could you retest with the attached
patch file applied and let me know if that fixes the problem?


Yeah it fixed the problem: no more oops in 1000 kernel boot tests. Thank you!


Whoa, 1000 boots. Thank you for being so thorough :-)

Regards,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [brcmfmac] BUG: unable to handle kernel paging request at ffffffff82196446

[Arend van Spriel]

On 09/23/2013 02:14 PM, Fengguang Wu wrote:

On Mon, Sep 16, 2013 at 11:15:53AM +0200, Arend van Spriel wrote:

On 09/02/2013 12:23 PM, Fengguang Wu wrote:

Greetings,

I got the below dmesg and the first bad commit is


Hi Fengguang,

I could not reproduce this issue. Could you retest with the attached
patch file applied and let me know if that fixes the problem?


Yeah it fixed the problem: no more oops in 1000 kernel boot tests. Thank you!


Whoa, 1000 boots. Thank you for being so thorough :-)

Regards,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [brcmfmac] BUG: unable to handle kernel paging request at ffffffff82196446

[Arend van Spriel]

On 09/02/2013 12:23 PM, Fengguang Wu wrote:

Greetings,

I got the below dmesg and the first bad commit is


Hi Fengguang,

I could not reproduce this issue. Could you retest with the attached 
patch file applied and let me know if that fixes the problem?


Regards,
Arend


commit 668761ac01d6f5a36b8e5a24d4e154550e2c4c3b
Author: Hante Meuleman 
Date:   Fri Apr 12 10:55:55 2013 +0200

 brcmfmac: define and use platform specific data for SDIO.

 This patch adds support for platform specific data for SDIO
 fullmac devices. Currently OOB interrupts are configured by Kconfig
 BRCMFMAC_SDIO_OOB but that is now determined dynamically by checking
 availibility of platform data.

 Cc: Hauke Mehrtens 
 Reviewed-by: Arend Van Spriel 
 Reviewed-by: Franky (Zhenhui) Lin 
 Reviewed-by: Pieter-Paul Giesberts 
 Reviewed-by: Piotr Haber 
 Signed-off-by: Hante Meuleman 
 Signed-off-by: Arend van Spriel 
 Signed-off-by: John W. Linville 


[   48.966342] Switched to clocksource tsc
[   48.970002] kernel tried to execute NX-protected page - exploit attempt? 
(uid: 0)
[   48.970851] BUG: unable to handle kernel paging request at 82196446
[   48.970957] IP: [] classes_init+0x26/0x26
[   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 82196163
[   48.970957] Oops: 0011 [#1]
[   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 
3.11.0-rc7-00444-gc52dd7f #23
[   48.970957] Workqueue: events brcmf_driver_init
[   48.970957] task: 881d2000 ti: 881d4000 task.ti: 
881d4000
[   48.970957] RIP: 0010:[]  [] 
classes_init+0x26/0x26
[   48.970957] RSP: :881d5d40  EFLAGS: 0286
[   48.970957] RAX: 0001 RBX: 820c5620 RCX: 
[   48.970957] RDX: 0001 RSI: 816f7380 RDI: 820c56c0
[   48.970957] RBP: 881d5d50 R08: 881d2508 R09: 0002
[   48.970957] R10:  R11: 0001f7ce298c5620 R12: 881c76b0
[   48.970957] R13: 81e91d40 R14:  R15: 88000e0ce300
[   48.970957] FS:  () GS:81e84000() 
knlGS:
[   48.970957] CS:  0010 DS:  ES:  CR0: 8005003b
[   48.970957] CR2: 82196446 CR3: 01e75000 CR4: 06b0
[   48.970957] DR0:  DR1:  DR2: 
[   48.970957] DR3:  DR6:  DR7: 
[   48.970957] Stack:
[   48.970957]  816f7df8 820c5620 881d5d60 
816eeec9
[   48.970957]  881d5de0 81073dc5 81073d68 
881d5db8
[   48.970957]  0086 820c5620 824f7fd0 

[   48.970957] Call Trace:
[   48.970957]  [] ? brcmf_sdio_init+0x18/0x70
[   48.970957]  [] brcmf_driver_init+0x9/0x10
[   48.970957]  [] process_one_work+0x1d5/0x480
[   48.970957]  [] ? process_one_work+0x178/0x480
[   48.970957]  [] worker_thread+0x118/0x3a0
[   48.970957]  [] ? process_one_work+0x480/0x480
[   48.970957]  [] kthread+0xe7/0xf0
[   48.970957]  [] ? finish_task_switch.constprop.57+0x37/0xd0
[   48.970957]  [] ? __kthread_parkme+0x80/0x80
[   48.970957]  [] ret_from_fork+0x7a/0xb0
[   48.970957]  [] ? __kthread_parkme+0x80/0x80
[   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc  cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[   48.970957] RIP  [] classes_init+0x26/0x26
[   48.970957]  RSP 
[   48.970957] CR2: 82196446
[   48.970957] ---[ end trace 62980817cd525f14 ]---

git bisect start v3.10 v3.9 --
git bisect  bad 20b4fb485227404329e41ad15588afad3df23050  # 12:16  9-  
Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good 19b344efa35dbc253e2d10403dafe6aafda73c56  # 17:54800+  
Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git bisect  bad 20074f357da4a637430aec2879c9d864c5d2c23c  # 18:03  1-  
filter: fix va_list build error
git bisect good 953c96e0d85615d1ab1f100e525d376053294dc2  # 21:38800+  tg3: 
Use bool not int
git bisect  bad 4de41bef3e075dbc787f7c53b3562f23295f1d6d  # 22:21102-  
wil6210: Use cached copy of Tx descriptor
git bisect good e73dcfbf061b524fe9aaef56cf3c2e234a45ec19  # 01:19800+  
Bluetooth: hidp: fix sending output reports on intr channel
git bisect good c79490e1b5ebf35415147fe06f02d8e77ccfe6d4  # 07:18800+  NFC: 
pn533: Avoid function declarations
git bisect  bad 06d961a8e210035bff7e82f466107f9ab4a8fd94  # 07:49 55-  
mac80211/minstrel: use the new rate control API
git bisect good 97990a060e6757f48b931a3946b17c1c4362c3fb  # 10:43800+  
nl80211: allow using wdev identifiers to get scan results
git bisect  bad 31ed07dc1e83b7926ce8ee2215ea21599a215990  # 11:15 77-  
brcmfmac: remove ifidx variable from

Re: [brcmfmac] BUG: unable to handle kernel paging request at ffffffff82196446

[Arend van Spriel]

On 09/02/2013 12:23 PM, Fengguang Wu wrote:

Greetings,

I got the below dmesg and the first bad commit is


Hi Fengguang,

I could not reproduce this issue. Could you retest with the attached 
patch file applied and let me know if that fixes the problem?


Regards,
Arend


commit 668761ac01d6f5a36b8e5a24d4e154550e2c4c3b
Author: Hante Meuleman meule...@broadcom.com
Date:   Fri Apr 12 10:55:55 2013 +0200

 brcmfmac: define and use platform specific data for SDIO.

 This patch adds support for platform specific data for SDIO
 fullmac devices. Currently OOB interrupts are configured by Kconfig
 BRCMFMAC_SDIO_OOB but that is now determined dynamically by checking
 availibility of platform data.

 Cc: Hauke Mehrtens ha...@hauke-m.de
 Reviewed-by: Arend Van Spriel ar...@broadcom.com
 Reviewed-by: Franky (Zhenhui) Lin fran...@broadcom.com
 Reviewed-by: Pieter-Paul Giesberts piete...@broadcom.com
 Reviewed-by: Piotr Haber pha...@broadcom.com
 Signed-off-by: Hante Meuleman meule...@broadcom.com
 Signed-off-by: Arend van Spriel ar...@broadcom.com
 Signed-off-by: John W. Linville linvi...@tuxdriver.com


[   48.966342] Switched to clocksource tsc
[   48.970002] kernel tried to execute NX-protected page - exploit attempt? 
(uid: 0)
[   48.970851] BUG: unable to handle kernel paging request at 82196446
[   48.970957] IP: [82196446] classes_init+0x26/0x26
[   48.970957] PGD 1e76067 PUD 1e77063 PMD f388063 PTE 82196163
[   48.970957] Oops: 0011 [#1]
[   48.970957] CPU: 0 PID: 17 Comm: kworker/0:1 Not tainted 
3.11.0-rc7-00444-gc52dd7f #23
[   48.970957] Workqueue: events brcmf_driver_init
[   48.970957] task: 881d2000 ti: 881d4000 task.ti: 
881d4000
[   48.970957] RIP: 0010:[82196446]  [82196446] 
classes_init+0x26/0x26
[   48.970957] RSP: :881d5d40  EFLAGS: 0286
[   48.970957] RAX: 0001 RBX: 820c5620 RCX: 
[   48.970957] RDX: 0001 RSI: 816f7380 RDI: 820c56c0
[   48.970957] RBP: 881d5d50 R08: 881d2508 R09: 0002
[   48.970957] R10:  R11: 0001f7ce298c5620 R12: 881c76b0
[   48.970957] R13: 81e91d40 R14:  R15: 88000e0ce300
[   48.970957] FS:  () GS:81e84000() 
knlGS:
[   48.970957] CS:  0010 DS:  ES:  CR0: 8005003b
[   48.970957] CR2: 82196446 CR3: 01e75000 CR4: 06b0
[   48.970957] DR0:  DR1:  DR2: 
[   48.970957] DR3:  DR6:  DR7: 
[   48.970957] Stack:
[   48.970957]  816f7df8 820c5620 881d5d60 
816eeec9
[   48.970957]  881d5de0 81073dc5 81073d68 
881d5db8
[   48.970957]  0086 820c5620 824f7fd0 

[   48.970957] Call Trace:
[   48.970957]  [816f7df8] ? brcmf_sdio_init+0x18/0x70
[   48.970957]  [816eeec9] brcmf_driver_init+0x9/0x10
[   48.970957]  [81073dc5] process_one_work+0x1d5/0x480
[   48.970957]  [81073d68] ? process_one_work+0x178/0x480
[   48.970957]  [81074188] worker_thread+0x118/0x3a0
[   48.970957]  [81074070] ? process_one_work+0x480/0x480
[   48.970957]  [8107aa17] kthread+0xe7/0xf0
[   48.970957]  [810829f7] ? finish_task_switch.constprop.57+0x37/0xd0
[   48.970957]  [8107a930] ? __kthread_parkme+0x80/0x80
[   48.970957]  [81a6923a] ret_from_fork+0x7a/0xb0
[   48.970957]  [8107a930] ? __kthread_parkme+0x80/0x80
[   48.970957] Code: cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc 
cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc cc
[   48.970957] RIP  [82196446] classes_init+0x26/0x26
[   48.970957]  RSP 881d5d40
[   48.970957] CR2: 82196446
[   48.970957] ---[ end trace 62980817cd525f14 ]---

git bisect start v3.10 v3.9 --
git bisect  bad 20b4fb485227404329e41ad15588afad3df23050  # 12:16  9-  
Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs
git bisect good 19b344efa35dbc253e2d10403dafe6aafda73c56  # 17:54800+  
Merge branch 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/hid
git bisect  bad 20074f357da4a637430aec2879c9d864c5d2c23c  # 18:03  1-  
filter: fix va_list build error
git bisect good 953c96e0d85615d1ab1f100e525d376053294dc2  # 21:38800+  tg3: 
Use bool not int
git bisect  bad 4de41bef3e075dbc787f7c53b3562f23295f1d6d  # 22:21102-  
wil6210: Use cached copy of Tx descriptor
git bisect good e73dcfbf061b524fe9aaef56cf3c2e234a45ec19  # 01:19800+  
Bluetooth: hidp: fix sending output reports on intr channel
git bisect good c79490e1b5ebf35415147fe06f02d8e77ccfe6d4

Re: access efi variables

[Arend van Spriel]

On 09/14/13 00:37, H. Peter Anvin wrote:

On 09/13/2013 08:37 AM, Arend van Spriel wrote:

I need to obtain a uefi variable so I went looking at the API in
include/linux/efi.h. I found the following definition:

But according to the specs the variable I need to obtain is 2k bytes.
Should I expect trouble :-p



efivarfs doesn't have those limitations.


Thanks, Peter

Looking into efivarfs it seems to use the functions that I looked at in 
efi.h so I guess I am misinterpreting the 1024 bytes limitation in the 
comment (either that or you are mistaken ;-) ). I need to access the 
variable from within a device driver so using efivarfs does not feel 
like the way to go here.


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: access efi variables

[Arend van Spriel]

On 09/14/13 00:37, H. Peter Anvin wrote:

On 09/13/2013 08:37 AM, Arend van Spriel wrote:

I need to obtain a uefi variable so I went looking at the API in
include/linux/efi.h. I found the following definition:

But according to the specs the variable I need to obtain is 2k bytes.
Should I expect trouble :-p



efivarfs doesn't have those limitations.


Thanks, Peter

Looking into efivarfs it seems to use the functions that I looked at in 
efi.h so I guess I am misinterpreting the 1024 bytes limitation in the 
comment (either that or you are mistaken ;-) ). I need to access the 
variable from within a device driver so using efivarfs does not feel 
like the way to go here.


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: access efi variables

[Arend van Spriel]

On 09/13/2013 05:37 PM, Arend van Spriel wrote:

I need to obtain a uefi variable so I went looking at the API in
include/linux/efi.h. I found the following definition:

/*
  * The maximum size of VariableName + Data = 1024
  * Therefore, it's reasonable to save that much
  * space in each part of the structure,
  * and we use a page for reading/writing.
  */

struct efi_variable {
 efi_char16_t  VariableName[1024/sizeof(efi_char16_t)];
 efi_guid_tVendorGuid;
 unsigned long DataSize;
 __u8  Data[1024];
 efi_status_t  Status;
 __u32 Attributes;
} __attribute__((packed));

But according to the specs the variable I need to obtain is 2k bytes.


Maybe clarify that "the specs" is basically the feature information I 
received internally here.



Should I expect trouble :-p

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

access efi variables

[Arend van Spriel]

I need to obtain a uefi variable so I went looking at the API in 
include/linux/efi.h. I found the following definition:


/*
 * The maximum size of VariableName + Data = 1024
 * Therefore, it's reasonable to save that much
 * space in each part of the structure,
 * and we use a page for reading/writing.
 */

struct efi_variable {
efi_char16_t  VariableName[1024/sizeof(efi_char16_t)];
efi_guid_tVendorGuid;
unsigned long DataSize;
__u8  Data[1024];
efi_status_t  Status;
__u32 Attributes;
} __attribute__((packed));

But according to the specs the variable I need to obtain is 2k bytes. 
Should I expect trouble :-p


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

access efi variables

[Arend van Spriel]

I need to obtain a uefi variable so I went looking at the API in 
include/linux/efi.h. I found the following definition:


/*
 * The maximum size of VariableName + Data = 1024
 * Therefore, it's reasonable to save that much
 * space in each part of the structure,
 * and we use a page for reading/writing.
 */

struct efi_variable {
efi_char16_t  VariableName[1024/sizeof(efi_char16_t)];
efi_guid_tVendorGuid;
unsigned long DataSize;
__u8  Data[1024];
efi_status_t  Status;
__u32 Attributes;
} __attribute__((packed));

But according to the specs the variable I need to obtain is 2k bytes. 
Should I expect trouble :-p


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: access efi variables

[Arend van Spriel]

On 09/13/2013 05:37 PM, Arend van Spriel wrote:

I need to obtain a uefi variable so I went looking at the API in
include/linux/efi.h. I found the following definition:

/*
  * The maximum size of VariableName + Data = 1024
  * Therefore, it's reasonable to save that much
  * space in each part of the structure,
  * and we use a page for reading/writing.
  */

struct efi_variable {
 efi_char16_t  VariableName[1024/sizeof(efi_char16_t)];
 efi_guid_tVendorGuid;
 unsigned long DataSize;
 __u8  Data[1024];
 efi_status_t  Status;
 __u32 Attributes;
} __attribute__((packed));

But according to the specs the variable I need to obtain is 2k bytes.


Maybe clarify that the specs is basically the feature information I 
received internally here.



Should I expect trouble :-p

Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 30 (brcmfmac)

[Arend van Spriel]

On 08/31/13 20:40, Hauke Mehrtens wrote:

On 08/31/2013 08:21 PM, Arend van Spriel wrote:

On 08/31/13 19:37, Geert Uytterhoeven wrote:

On Fri, Aug 30, 2013 at 11:12 PM, Randy Dunlap
wrote:

This bool kconfig symbol:

config BRCMFMAC_SDIO
  bool "SDIO bus interface support for FullMAC driver"
  depends on MMC

allows BRCMFMAC_SDIO to be y even when MMC=m.

Is there a reasonable solution to this?


Actually, BRCMFMAC should be built in same form as the MMC and/or USB,
but only when BRCMFMAC_SDIO or BRCMFMAC_USB are selected.

So valid combinations are:
MMC=m, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =>  BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =>  BRCMFMAC=m
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =>  BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n =>  BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y =>  BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n =>  BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y =>  BRCMFMAC=m
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =>  BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n =>  BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y =>  BRCMFMAC=m|y

Not sure how to express the above.


This should be expressed with this Kconfig:

config BRCMFMAC_USB
bool "USB bus interface support for FullMAC driver"
depends on (USB = y || USB = BRCMFMAC)
depends on BRCMFMAC

config BRCMFMAC_SDIO
bool "SDIO bus interface support for FullMAC driver"
depends on (MMC = y || MMC = BRCMFMAC)
depends on BRCMFMAC
select FW_LOADER

I haven't tested it, but we had a similar problem in b43 and fixed it
like this.


Thanks, Hauke

I will create a patch fixing this.

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 30 (brcmfmac)

[Arend van Spriel]

On 08/31/13 20:40, Hauke Mehrtens wrote:

On 08/31/2013 08:21 PM, Arend van Spriel wrote:

On 08/31/13 19:37, Geert Uytterhoeven wrote:

On Fri, Aug 30, 2013 at 11:12 PM, Randy Dunlaprdun...@infradead.org
wrote:

This bool kconfig symbol:

config BRCMFMAC_SDIO
  bool SDIO bus interface support for FullMAC driver
  depends on MMC

allows BRCMFMAC_SDIO to be y even when MMC=m.

Is there a reasonable solution to this?


Actually, BRCMFMAC should be built in same form as the MMC and/or USB,
but only when BRCMFMAC_SDIO or BRCMFMAC_USB are selected.

So valid combinations are:
MMC=m, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =  BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =  BRCMFMAC=m
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =  BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n =  BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y =  BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n =  BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y =  BRCMFMAC=m
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y =  BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n =  BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y =  BRCMFMAC=m|y

Not sure how to express the above.


This should be expressed with this Kconfig:

config BRCMFMAC_USB
bool USB bus interface support for FullMAC driver
depends on (USB = y || USB = BRCMFMAC)
depends on BRCMFMAC

config BRCMFMAC_SDIO
bool SDIO bus interface support for FullMAC driver
depends on (MMC = y || MMC = BRCMFMAC)
depends on BRCMFMAC
select FW_LOADER

I haven't tested it, but we had a similar problem in b43 and fixed it
like this.


Thanks, Hauke

I will create a patch fixing this.

Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 30 (brcmfmac)

[Arend van Spriel]

On 08/31/13 19:37, Geert Uytterhoeven wrote:

On Fri, Aug 30, 2013 at 11:12 PM, Randy Dunlap  wrote:

This bool kconfig symbol:

config BRCMFMAC_SDIO
 bool "SDIO bus interface support for FullMAC driver"
 depends on MMC

allows BRCMFMAC_SDIO to be y even when MMC=m.

Is there a reasonable solution to this?


Actually, BRCMFMAC should be built in same form as the MMC and/or USB, 
but only when BRCMFMAC_SDIO or BRCMFMAC_USB are selected.


So valid combinations are:
MMC=m, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y => BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y => BRCMFMAC=m
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y => BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n => BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y => BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n => BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y => BRCMFMAC=m
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y => BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n => BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y => BRCMFMAC=m|y

Not sure how to express the above.

Gr. AvS


In order of preference:
1. Make it tristate
2. depends on MMC=y

However, the first solution cannot be used as there are several
"#ifdef CONFIG_BRCMFMAC_SDIO" in the code itself.

Note that there's a similar issue with BRCMFMAC_USB and USB.

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
 -- Linus Torvalds




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 30 (brcmfmac)

[Arend van Spriel]

On 08/31/13 19:37, Geert Uytterhoeven wrote:

On Fri, Aug 30, 2013 at 11:12 PM, Randy Dunlaprdun...@infradead.org  wrote:

This bool kconfig symbol:

config BRCMFMAC_SDIO
 bool SDIO bus interface support for FullMAC driver
 depends on MMC

allows BRCMFMAC_SDIO to be y even when MMC=m.

Is there a reasonable solution to this?


Actually, BRCMFMAC should be built in same form as the MMC and/or USB, 
but only when BRCMFMAC_SDIO or BRCMFMAC_USB are selected.


So valid combinations are:
MMC=m, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y = BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y = BRCMFMAC=m
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y = BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n = BRCMFMAC=m
MMC=m, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y = BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n = BRCMFMAC=m|y
MMC=y, USB=m, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y = BRCMFMAC=m
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=y = BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=y, BRCMFMAC_USB=n = BRCMFMAC=m|y
MMC=y, USB=y, BRCMFMAC_SDIO=n, BRCMFMAC_USB=y = BRCMFMAC=m|y

Not sure how to express the above.

Gr. AvS


In order of preference:
1. Make it tristate
2. depends on MMC=y

However, the first solution cannot be used as there are several
#ifdef CONFIG_BRCMFMAC_SDIO in the code itself.

Note that there's a similar issue with BRCMFMAC_USB and USB.

Gr{oetje,eeting}s,

 Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- ge...@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
 -- Linus Torvalds




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/21/13 14:38, Josh Boyer wrote:

On Wed, Aug 21, 2013 at 4:52 AM, Arend van Spriel  wrote:

Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck
support
and only change brcmsmac.



We have a number of users hitting this in Fedora 18 and 19 now.  We're
tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
and I'm sure we can find people to test easily.



There is already another one (possibly) dealing with the same issue:

https://bugzilla.redhat.com/show_bug.cgi?id=989269

One of them should probably be flagged as duplicate.



If you have a patch disabling cck in brcmsmac, I'd be happy to build a
kernel for people.  If that's going to be some time coming, perhaps
it's better to grab Felix's patch on a temporary basis?



I think it is better to grab Felix's patch because as we both observed there
is stuff missing in brcmsmac to deal with CCK rates and A-MPDU packet
aggregation.


OK, thanks.

Felix, are you going to send that upstream?


It already has been sent: 
http://mid.gmane.org/1377020634-27064-1-git-send-email-...@openwrt.org


Johannes has submitted it to John so it is getting there soon(ish).


josh


Regards,
Arend



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/21/2013 02:11 AM, Josh Boyer wrote:

On Tue, Aug 20, 2013 at 4:15 AM, Arend van Spriel  wrote:

On 08/20/2013 06:56 AM, Felix Fietkau wrote:


On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:


On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:


On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
 wrote:


On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:


Hi guys,

Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.

The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:

brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx

I bisected the problem and the first bad commit is

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau 
Date:   Fri Jun 28 21:04:35 2013 +0200

  mac80211/minstrel_ht: fix cck rate sampling

  commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

Reverting it on top of .7 fixes the problem.

I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.

Let me know if you need any more information.



Do you have this same problem with 3.11-rc6 as well?



Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.



Great, thanks.

Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?


I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.



Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck support
and only change brcmsmac.


We have a number of users hitting this in Fedora 18 and 19 now.  We're
tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
and I'm sure we can find people to test easily.


There is already another one (possibly) dealing with the same issue:

https://bugzilla.redhat.com/show_bug.cgi?id=989269

One of them should probably be flagged as duplicate.


If you have a patch disabling cck in brcmsmac, I'd be happy to build a
kernel for people.  If that's going to be some time coming, perhaps
it's better to grab Felix's patch on a temporary basis?


I think it is better to grab Felix's patch because as we both observed 
there is stuff missing in brcmsmac to deal with CCK rates and A-MPDU 
packet aggregation.


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/21/2013 02:11 AM, Josh Boyer wrote:

On Tue, Aug 20, 2013 at 4:15 AM, Arend van Spriel ar...@broadcom.com wrote:

On 08/20/2013 06:56 AM, Felix Fietkau wrote:


On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:


On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:


On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:


On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:


Hi guys,

Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.

The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:

brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx

I bisected the problem and the first bad commit is

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau n...@openwrt.org
Date:   Fri Jun 28 21:04:35 2013 +0200

  mac80211/minstrel_ht: fix cck rate sampling

  commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

Reverting it on top of .7 fixes the problem.

I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.

Let me know if you need any more information.



Do you have this same problem with 3.11-rc6 as well?



Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.



Great, thanks.

Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?


I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.



Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck support
and only change brcmsmac.


We have a number of users hitting this in Fedora 18 and 19 now.  We're
tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
and I'm sure we can find people to test easily.


There is already another one (possibly) dealing with the same issue:

https://bugzilla.redhat.com/show_bug.cgi?id=989269

One of them should probably be flagged as duplicate.


If you have a patch disabling cck in brcmsmac, I'd be happy to build a
kernel for people.  If that's going to be some time coming, perhaps
it's better to grab Felix's patch on a temporary basis?


I think it is better to grab Felix's patch because as we both observed 
there is stuff missing in brcmsmac to deal with CCK rates and A-MPDU 
packet aggregation.


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/21/13 14:38, Josh Boyer wrote:

On Wed, Aug 21, 2013 at 4:52 AM, Arend van Sprielar...@broadcom.com  wrote:

Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck
support
and only change brcmsmac.



We have a number of users hitting this in Fedora 18 and 19 now.  We're
tracking it with https://bugzilla.redhat.com/show_bug.cgi?id=998080
and I'm sure we can find people to test easily.



There is already another one (possibly) dealing with the same issue:

https://bugzilla.redhat.com/show_bug.cgi?id=989269

One of them should probably be flagged as duplicate.



If you have a patch disabling cck in brcmsmac, I'd be happy to build a
kernel for people.  If that's going to be some time coming, perhaps
it's better to grab Felix's patch on a temporary basis?



I think it is better to grab Felix's patch because as we both observed there
is stuff missing in brcmsmac to deal with CCK rates and A-MPDU packet
aggregation.


OK, thanks.

Felix, are you going to send that upstream?


It already has been sent: 
http://mid.gmane.org/1377020634-27064-1-git-send-email-...@openwrt.org


Johannes has submitted it to John so it is getting there soon(ish).


josh


Regards,
Arend



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/20/2013 10:36 AM, Tom Gundersen wrote:

On Tue, Aug 20, 2013 at 4:15 PM, Arend van Spriel  wrote:

On 08/20/2013 06:56 AM, Felix Fietkau wrote:


On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:


On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:


On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
 wrote:


On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:


Hi guys,

Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.

The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:

brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx

I bisected the problem and the first bad commit is

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau 
Date:   Fri Jun 28 21:04:35 2013 +0200

  mac80211/minstrel_ht: fix cck rate sampling

  commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

Reverting it on top of .7 fixes the problem.

I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.

Let me know if you need any more information.



Do you have this same problem with 3.11-rc6 as well?



Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.



Great, thanks.

Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?


I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.



Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck support
and only change brcmsmac.


Hi Arend,

In case you cannot reproduce, let me know if I can help with testing patches.


So far I have not been able to reproduce it. I have a patch to avoid the 
oops, but the transmit of the related frames will fail in the device so 
it is not a real fix. I will let you you know.


Regards,
Arend


Cheers,

Tom




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/20/2013 06:56 AM, Felix Fietkau wrote:

On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:

On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:

On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
 wrote:

On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:

Hi guys,

Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.

The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:

brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx

I bisected the problem and the first bad commit is

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau 
Date:   Fri Jun 28 21:04:35 2013 +0200

 mac80211/minstrel_ht: fix cck rate sampling

 commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

Reverting it on top of .7 fixes the problem.

I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.

Let me know if you need any more information.


Do you have this same problem with 3.11-rc6 as well?


Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.


Great, thanks.

Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?

I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.


Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck 
fallback rates, because it should. Maybe it is better to flag no cck 
support and only change brcmsmac.


Regards,
Arend


- Felix
---
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_RC_TABLE  = 1<<24,
IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF  = 1<<25,
IEEE80211_HW_TIMING_BEACON_ONLY = 1<<26,
+   IEEE80211_HW_SUPPORTS_HT_CCK_RATES  = 1<<27,
  };

  /**
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
if (sband->band != IEEE80211_BAND_2GHZ)
return;

+   if (!(mp->hw->flags & IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
+   return;
+
mi->cck_supported = 0;
mi->cck_supported_short = 0;
for (i = 0; i < 4; i++) {
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
-   IEEE80211_HW_SUPPORTS_RC_TABLE;
+   IEEE80211_HW_SUPPORTS_RC_TABLE |
+   IEEE80211_HW_SUPPORTS_HT_CCK_RATES;

if (sc->sc_ah->caps.hw_caps & ATH9K_HW_CAP_HT) {
hw->flags |= IEEE80211_HW_AMPDU_AGGREGATION;
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
 IEEE80211_HW_PS_NULLFUNC_STACK |
 IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
 IEEE80211_HW_SUPPORTS_RC_TABLE |
-IEEE80211_HW_SIGNAL_DBM;
+IEEE80211_HW_SIGNAL_DBM |
+IEEE80211_HW_SUPPORTS_HT_CCK_RATES;

if (!modparam_noht) {
/*
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_AMPDU_AGGREGATION |
-   IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+   IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+   IEEE80211_HW_SUPPORTS_HT_CCK_RATES;

/*
 * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/20/2013 06:56 AM, Felix Fietkau wrote:

On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:

On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:

On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:

On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:

Hi guys,

Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.

The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:

brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx

I bisected the problem and the first bad commit is

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau n...@openwrt.org
Date:   Fri Jun 28 21:04:35 2013 +0200

 mac80211/minstrel_ht: fix cck rate sampling

 commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

Reverting it on top of .7 fixes the problem.

I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.

Let me know if you need any more information.


Do you have this same problem with 3.11-rc6 as well?


Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.


Great, thanks.

Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?

I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.


Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck 
fallback rates, because it should. Maybe it is better to flag no cck 
support and only change brcmsmac.


Regards,
Arend


- Felix
---
--- a/include/net/mac80211.h
+++ b/include/net/mac80211.h
@@ -1501,6 +1501,7 @@ enum ieee80211_hw_flags {
IEEE80211_HW_SUPPORTS_RC_TABLE  = 124,
IEEE80211_HW_P2P_DEV_ADDR_FOR_INTF  = 125,
IEEE80211_HW_TIMING_BEACON_ONLY = 126,
+   IEEE80211_HW_SUPPORTS_HT_CCK_RATES  = 127,
  };

  /**
--- a/net/mac80211/rc80211_minstrel_ht.c
+++ b/net/mac80211/rc80211_minstrel_ht.c
@@ -828,6 +828,9 @@ minstrel_ht_update_cck(struct minstrel_p
if (sband-band != IEEE80211_BAND_2GHZ)
return;

+   if (!(mp-hw-flags  IEEE80211_HW_SUPPORTS_HT_CCK_RATES))
+   return;
+
mi-cck_supported = 0;
mi-cck_supported_short = 0;
for (i = 0; i  4; i++) {
--- a/drivers/net/wireless/ath/ath9k/init.c
+++ b/drivers/net/wireless/ath/ath9k/init.c
@@ -807,7 +807,8 @@ void ath9k_set_hw_capab(struct ath_softc
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_SPECTRUM_MGMT |
IEEE80211_HW_REPORTS_TX_ACK_STATUS |
-   IEEE80211_HW_SUPPORTS_RC_TABLE;
+   IEEE80211_HW_SUPPORTS_RC_TABLE |
+   IEEE80211_HW_SUPPORTS_HT_CCK_RATES;

if (sc-sc_ah-caps.hw_caps  ATH9K_HW_CAP_HT) {
hw-flags |= IEEE80211_HW_AMPDU_AGGREGATION;
--- a/drivers/net/wireless/ath/carl9170/main.c
+++ b/drivers/net/wireless/ath/carl9170/main.c
@@ -1878,7 +1878,8 @@ void *carl9170_alloc(size_t priv_size)
 IEEE80211_HW_PS_NULLFUNC_STACK |
 IEEE80211_HW_NEED_DTIM_BEFORE_ASSOC |
 IEEE80211_HW_SUPPORTS_RC_TABLE |
-IEEE80211_HW_SIGNAL_DBM;
+IEEE80211_HW_SIGNAL_DBM |
+IEEE80211_HW_SUPPORTS_HT_CCK_RATES;

if (!modparam_noht) {
/*
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -6327,7 +6327,8 @@ static int rt2800_probe_hw_mode(struct r
IEEE80211_HW_SUPPORTS_PS |
IEEE80211_HW_PS_NULLFUNC_STACK |
IEEE80211_HW_AMPDU_AGGREGATION |
-   IEEE80211_HW_REPORTS_TX_ACK_STATUS;
+   IEEE80211_HW_REPORTS_TX_ACK_STATUS |
+   IEEE80211_HW_SUPPORTS_HT_CCK_RATES;

/*
 * Don't set IEEE80211_HW_HOST_BROADCAST_PS_BUFFERING for USB devices

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [REGRESSION] 3.10.{6,7} crashes on network activity

[Arend van Spriel]

On 08/20/2013 10:36 AM, Tom Gundersen wrote:

On Tue, Aug 20, 2013 at 4:15 PM, Arend van Spriel ar...@broadcom.com wrote:

On 08/20/2013 06:56 AM, Felix Fietkau wrote:


On 2013-08-20 2:28 AM, Greg Kroah-Hartman wrote:


On Tue, Aug 20, 2013 at 08:26:11AM +0800, Tom Gundersen wrote:


On Tue, Aug 20, 2013 at 8:03 AM, Greg Kroah-Hartman
gre...@linuxfoundation.org wrote:


On Tue, Aug 20, 2013 at 07:59:47AM +0800, Tom Gundersen wrote:


Hi guys,

Starting with 3.10.6 (and still present in .7) I get an oops on
connecting to the network.

The attached picture shows the oops. In case it does not reach the ML,
the top of the call trace reads:

brcms_c_compute_rtscts_dur
brcms_c_ampdu_finalize
ampdu_finalize
dma_txfast
brcms_c_txfifo
brcms_c_sendpkt_mac80211
brcms_ops_tx
__ieee80211_tx

I bisected the problem and the first bad commit is

commit ef47a5e4f1aaf1d0e2e6875e34b2c9595897bef6
Author: Felix Fietkau n...@openwrt.org
Date:   Fri Jun 28 21:04:35 2013 +0200

  mac80211/minstrel_ht: fix cck rate sampling

  commit 1cd158573951f737fbc878a35cb5eb47bf9af3d5 upstream.

Reverting it on top of .7 fixes the problem.

I had the same (I suppose) problem on mainline some time ago, but I
have not bisected it, verified that the problem still occurs there, or
checked if reverting the upstream patch fixes it. I'd be happy to do
that if it would help though.

Let me know if you need any more information.



Do you have this same problem with 3.11-rc6 as well?



Yes, I just confirmed. I also confirmed that reverting the mainline
commit on top of -rc6 fixes the problem.



Great, thanks.

Felix and Johannes, any chance we can get this reverted in Linus tree
soon, and push that revert back to the 3.10 stable tree as well?


I'd like to avoid a revert, since that will simply replace one set of
issues with another. Let's limit the use of the feature that brcmsmac
can't handle to drivers that are known to work with it. Tom, Please
test this patch to see if it fixes your issue.



Hi Felix,

I have been diving into root causing why brcmsmac can not handle cck
fallback rates, because it should. Maybe it is better to flag no cck support
and only change brcmsmac.


Hi Arend,

In case you cannot reproduce, let me know if I can help with testing patches.


So far I have not been able to reproduce it. I have a patch to avoid the 
oops, but the transmit of the related frames will fail in the device so 
it is not a real fix. I will let you you know.


Regards,
Arend


Cheers,

Tom




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System suspend states and device driver suspend() callback

[Arend van Spriel]

On 08/16/2013 10:06 AM, Li Yang wrote:

Hi Guys,

Is there a standard way for the device drivers to know if the system
is going to “standby” mode or “mem” mode when the suspend() callbacks
are called?


what about implementing struct device_driver::suspend?

This is for driver level suspend operation, so not per-device.


Regards,

Leo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: System suspend states and device driver suspend() callback

[Arend van Spriel]

On 08/16/2013 10:06 AM, Li Yang wrote:

Hi Guys,

Is there a standard way for the device drivers to know if the system
is going to “standby” mode or “mem” mode when the suspend() callbacks
are called?


what about implementing struct device_driver::suspend?

This is for driver level suspend operation, so not per-device.


Regards,

Leo
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: brcsmac kernel panic

[Arend van Spriel]

On 08/12/2013 10:11 PM, Daniel Wagner wrote:

Hi Arend,

On 08/12/2013 12:38 PM, Arend van Spriel wrote:

On 08/11/2013 06:21 PM, Daniel Wagner wrote:

I just updated my laptop (MacBook Air 2012) from 3.11-rc3+ to 3.11-rc4+
and since then brcsmac crashes short after enabling it. Unfortunately, I
did also change some config flags in the area of cpufreq (enabling
p-state driver) so the configuration is not exactly the same. Before I
try to figure out what I have changed, I am posting the picture of the
crash. Maybe it is something obvious.

v3.11-rc4-197-gd92581f
http://www.monom.org/misc/brcmsmac/v3.11-rc4.config
http://www.monom.org/misc/brcmsmac/IMAG0064.jpg


Thanks, Daniel

I was looking at this issue two weeks ago and just got back from my
vacation. Can you apply the patch and send me a kernel log?


Sure, the patch does the trick, the panic is gone.


Unfortunately, it results in a lot of error print and phy tx errors that 
has been reported by others. I think the two are related, but I have not 
root caused it yet. Your laptop may be usable now, but wireless 
performance is probably bad.


Too bad I can not reproduce the issue over here. Are you willing to test 
some patches when I got a better grasp on the issue?


Regards,
Arend


Sharing pictures, huh. What about this one :-p


No no, that isn't me, that is someone else! :P

cheers,
daniel





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: brcsmac kernel panic

[Arend van Spriel]

On 08/12/2013 10:11 PM, Daniel Wagner wrote:

Hi Arend,

On 08/12/2013 12:38 PM, Arend van Spriel wrote:

On 08/11/2013 06:21 PM, Daniel Wagner wrote:

I just updated my laptop (MacBook Air 2012) from 3.11-rc3+ to 3.11-rc4+
and since then brcsmac crashes short after enabling it. Unfortunately, I
did also change some config flags in the area of cpufreq (enabling
p-state driver) so the configuration is not exactly the same. Before I
try to figure out what I have changed, I am posting the picture of the
crash. Maybe it is something obvious.

v3.11-rc4-197-gd92581f
http://www.monom.org/misc/brcmsmac/v3.11-rc4.config
http://www.monom.org/misc/brcmsmac/IMAG0064.jpg


Thanks, Daniel

I was looking at this issue two weeks ago and just got back from my
vacation. Can you apply the patch and send me a kernel log?


Sure, the patch does the trick, the panic is gone.


Unfortunately, it results in a lot of error print and phy tx errors that 
has been reported by others. I think the two are related, but I have not 
root caused it yet. Your laptop may be usable now, but wireless 
performance is probably bad.


Too bad I can not reproduce the issue over here. Are you willing to test 
some patches when I got a better grasp on the issue?


Regards,
Arend


Sharing pictures, huh. What about this one :-p


No no, that isn't me, that is someone else! :P

cheers,
daniel





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn when using extern with function prototypes in .h files

[Arend van Spriel]

On 08/01/2013 02:21 PM, David Howells wrote:

Joe Perches  wrote:


Using the extern keyword on function prototypes is superfluous
visual noise so suggest removing it.

Using extern can cause unnecessary line wrapping at 80 columns
and unnecessarily long multi-line function prototypes.

Suggested-by: Hannes Frederic Sowa 
Signed-off-by: Joe Perches 


Nak.

The "extern" makes it much easier to pick out at a glance.


Really? Grouping function prototypes within the header file is much more 
helpful for spotting them.


Regards,
Arend


Please standardise on there _being_ externs if you must do this.

It's gratuitous change anyway and not worth the churn.

David
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/31/2013 11:26 PM, jonsm...@gmail.com wrote:

Alternatively you may be of the belief that it is impossible to get
rid of the board specific code. But x86 doesn't have any of it, why
should ARM?


Well, I am curious whether that will stay that way once x86 is truly 
moving into the embedded arena (if ever).


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/31/2013 11:26 PM, jonsm...@gmail.com wrote:

Alternatively you may be of the belief that it is impossible to get
rid of the board specific code. But x86 doesn't have any of it, why
should ARM?


Well, I am curious whether that will stay that way once x86 is truly 
moving into the embedded arena (if ever).


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] checkpatch: Warn when using extern with function prototypes in .h files

[Arend van Spriel]

On 08/01/2013 02:21 PM, David Howells wrote:

Joe Perches j...@perches.com wrote:


Using the extern keyword on function prototypes is superfluous
visual noise so suggest removing it.

Using extern can cause unnecessary line wrapping at 80 columns
and unnecessarily long multi-line function prototypes.

Suggested-by: Hannes Frederic Sowa han...@stressinduktion.org
Signed-off-by: Joe Perches j...@perches.com


Nak.

The extern makes it much easier to pick out at a glance.


Really? Grouping function prototypes within the header file is much more 
helpful for spotting them.


Regards,
Arend


Please standardise on there _being_ externs if you must do this.

It's gratuitous change anyway and not worth the churn.

David
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/29/2013 11:19 AM, Arend van Spriel wrote:

On 07/27/2013 10:01 PM, jonsm...@gmail.com wrote:

On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely
 wrote:

On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel
 wrote:

Let's see how many people go and scream if I say this: Too bad .dts
files
are not done using XML format as DT bindings could be described
using XML
Schema.


Draft an example and show us how it would look!  :-)  There is
absolutely nothing preventing us from expressing a DT in XML format,
or even using XSLT to define DT schema while still using our current
.dts syntax. It would be trivial to do lossless translation between
.dts syntax and xml.

The problem that I have with XML and XSLT is that it is very verbose
and not entirely friendly to mere-mortals. However, I'm more than
willing to be proved wrong on this point.


I considered this approach a while ago and discarded it. It would work
but it is just too much of a Frankenstein monster.


Ah, but he is so cute. At least I do not think it is more monstrous as
the bindings files. I just browsed through a couple of arm binding files
as I felt challenged to come up with an example. I did not get the
impression that there is some kind of template in place to get consitent
bindings descriptions.


Much cleaner to modify dtc to take a schema as part of the compilation
process. The schema language itself has no requirement to look like
DTS syntax. Whoever wrote dtc probably has a favorite language that
would be good for writing schemas in.


Not sure if I can follow here. I guess you mean the dts compilation,
right? There are tools freely available to validate XML files against
XSD specification files. As an example libxml2 has support for it. I
suspect it is not desired to have a dependency for DTC with an
out-of-tree library, but it could be incorporated and have DTC spew the
validation results.


crap. Probably not as libxml2 has MIT-license.

Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 10:01 PM, jonsm...@gmail.com wrote:

On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely  wrote:

On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel  wrote:

Let's see how many people go and scream if I say this: Too bad .dts files
are not done using XML format as DT bindings could be described using XML
Schema.


Draft an example and show us how it would look!  :-)  There is
absolutely nothing preventing us from expressing a DT in XML format,
or even using XSLT to define DT schema while still using our current
.dts syntax. It would be trivial to do lossless translation between
.dts syntax and xml.

The problem that I have with XML and XSLT is that it is very verbose
and not entirely friendly to mere-mortals. However, I'm more than
willing to be proved wrong on this point.


I considered this approach a while ago and discarded it. It would work
but it is just too much of a Frankenstein monster.


Ah, but he is so cute. At least I do not think it is more monstrous as 
the bindings files. I just browsed through a couple of arm binding files 
as I felt challenged to come up with an example. I did not get the 
impression that there is some kind of template in place to get consitent 
bindings descriptions.



Much cleaner to modify dtc to take a schema as part of the compilation
process. The schema language itself has no requirement to look like
DTS syntax. Whoever wrote dtc probably has a favorite language that
would be good for writing schemas in.


Not sure if I can follow here. I guess you mean the dts compilation, 
right? There are tools freely available to validate XML files against 
XSD specification files. As an example libxml2 has support for it. I 
suspect it is not desired to have a dependency for DTC with an 
out-of-tree library, but it could be incorporated and have DTC spew the 
validation results.


Regards,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 10:01 PM, jonsm...@gmail.com wrote:

On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely grant.lik...@secretlab.ca wrote:

On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel ar...@broadcom.com wrote:

Let's see how many people go and scream if I say this: Too bad .dts files
are not done using XML format as DT bindings could be described using XML
Schema.


Draft an example and show us how it would look!  :-)  There is
absolutely nothing preventing us from expressing a DT in XML format,
or even using XSLT to define DT schema while still using our current
.dts syntax. It would be trivial to do lossless translation between
.dts syntax and xml.

The problem that I have with XML and XSLT is that it is very verbose
and not entirely friendly to mere-mortals. However, I'm more than
willing to be proved wrong on this point.


I considered this approach a while ago and discarded it. It would work
but it is just too much of a Frankenstein monster.


Ah, but he is so cute. At least I do not think it is more monstrous as 
the bindings files. I just browsed through a couple of arm binding files 
as I felt challenged to come up with an example. I did not get the 
impression that there is some kind of template in place to get consitent 
bindings descriptions.



Much cleaner to modify dtc to take a schema as part of the compilation
process. The schema language itself has no requirement to look like
DTS syntax. Whoever wrote dtc probably has a favorite language that
would be good for writing schemas in.


Not sure if I can follow here. I guess you mean the dts compilation, 
right? There are tools freely available to validate XML files against 
XSD specification files. As an example libxml2 has support for it. I 
suspect it is not desired to have a dependency for DTC with an 
out-of-tree library, but it could be incorporated and have DTC spew the 
validation results.


Regards,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/29/2013 11:19 AM, Arend van Spriel wrote:

On 07/27/2013 10:01 PM, jonsm...@gmail.com wrote:

On Sat, Jul 27, 2013 at 3:45 PM, Grant Likely
grant.lik...@secretlab.ca wrote:

On Sat, Jul 27, 2013 at 4:59 AM, Arend van Spriel
ar...@broadcom.com wrote:

Let's see how many people go and scream if I say this: Too bad .dts
files
are not done using XML format as DT bindings could be described
using XML
Schema.


Draft an example and show us how it would look!  :-)  There is
absolutely nothing preventing us from expressing a DT in XML format,
or even using XSLT to define DT schema while still using our current
.dts syntax. It would be trivial to do lossless translation between
.dts syntax and xml.

The problem that I have with XML and XSLT is that it is very verbose
and not entirely friendly to mere-mortals. However, I'm more than
willing to be proved wrong on this point.


I considered this approach a while ago and discarded it. It would work
but it is just too much of a Frankenstein monster.


Ah, but he is so cute. At least I do not think it is more monstrous as
the bindings files. I just browsed through a couple of arm binding files
as I felt challenged to come up with an example. I did not get the
impression that there is some kind of template in place to get consitent
bindings descriptions.


Much cleaner to modify dtc to take a schema as part of the compilation
process. The schema language itself has no requirement to look like
DTS syntax. Whoever wrote dtc probably has a favorite language that
would be good for writing schemas in.


Not sure if I can follow here. I guess you mean the dts compilation,
right? There are tools freely available to validate XML files against
XSD specification files. As an example libxml2 has support for it. I
suspect it is not desired to have a dependency for DTC with an
out-of-tree library, but it could be incorporated and have DTC spew the
validation results.


crap. Probably not as libxml2 has MIT-license.

Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 12:36 PM, Tomasz Figa wrote:

On Saturday 27 of July 2013 12:24:24 Arend van Spriel wrote:

On 07/27/2013 11:51 AM, Tomasz Figa wrote:

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:

Long term, final goal is likely to be close to what Russell is
saying


Why is this a long term goal? Start today.


-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between
now
and then, and even when we're at the final state there will be need
to
have some sort of sandbox for development and test of future
bindings.


Why not just set up a git tree right away?


Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time
are
nothing but pain, but we're arguing that in circles anyway.


No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up
as
we go along.


We have currently a lot of broken bindings, because people didn't know
how to define ones and those they defined have not been properly
reviewed. Do you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable
and
well they probably are already de facto stable. This is mostly about
subsystem bindings and whatever already has many users, both made them
get more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply
broken. Take max8925 backlight driver, that Olof started this whole
discussion with, as an example. We need to sort them out before they
can be stabilized.


That is a nice summary of how we got from null to now and Richard seems
to be simply saying: let's stop mucking about and make this a project
with a well-defined process of dealing with staging and stable bindings
and keep stable bindings stable. Whether it should be within the kernel
repo as a separate subsystem or in an entire different repo is a trivial
decision, but still a decision that needs to be made.


Yes, basically that's our current situation.

Still, I would disagree about the decision being trivial, as each choice
will have further, and likely pretty significant, consequences on binding
maintenance, submission, review and for dependent things, like drivers or
platforms using such bindings. This needs to be discussed enough.


Apart from stable DT bindings I would love to see a DT compiler that
that next to DT syntax detects mistakes in properties used for the
selfish reason that I spent hours debugging regulator code, because I
typed vmmc_supply iso vmmc-supply. I did not go through all the
bindings, but this may require a more formal description so it could be
compiled/read in the DT compiler.


This bothered me as well and that's why I'm working on this. I still can't
get myself to write a very long mail (I'm more a coder than writer...)
about the whole idea, my proposal of how it could look and problems we
need to solve, but I'll try better this evening.


Let's see how many people go and scream if I say this: Too bad .dts 
files are not done using XML format as DT bindings could be described 
using XML Schema.


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 12:24 PM, Arend van Spriel wrote:

On 07/27/2013 11:51 AM, Tomasz Figa wrote:

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:

Long term, final goal is likely to be close to what Russell is saying


Why is this a long term goal? Start today.


-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between now
and then, and even when we're at the final state there will be need to
have some sort of sandbox for development and test of future bindings.


Why not just set up a git tree right away?


Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time are
nothing but pain, but we're arguing that in circles anyway.


No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up as
we go along.


We have currently a lot of broken bindings, because people didn't know
how
to define ones and those they defined have not been properly reviewed. Do
you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable and
well they probably are already de facto stable. This is mostly about
subsystem bindings and whatever already has many users, both made them
get
more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply broken.
Take max8925 backlight driver, that Olof started this whole discussion
with, as an example. We need to sort them out before they can be
stabilized.


That is a nice summary of how we got from null to now and Richard seems
to be simply saying: let's stop mucking about and make this a project
with a well-defined process of dealing with staging and stable bindings
and keep stable bindings stable. Whether it should be within the kernel
repo as a separate subsystem or in an entire different repo is a trivial
decision, but still a decision that needs to be made.

Apart from stable DT bindings I would love to see a DT compiler that
that next to DT syntax detects mistakes in properties used for the
selfish reason that I spent hours debugging regulator code, because I
typed vmmc_supply iso vmmc-supply. I did not go through all the
bindings, but this may require a more formal description so it could be
compiled/read in the DT compiler.


Oh, and the reason for my tinkering on dts is here:

http://mid.gmane.org/51e7aa24.6080...@broadcom.com

Happily using Pandaboard for my driver testing and than *kaboom*. 
board-omap4panda.c is gone although the device tree does not provide the 
same functionality. Of course, this is not about DT bindings.


Regards,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 11:51 AM, Tomasz Figa wrote:

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:

Long term, final goal is likely to be close to what Russell is saying


Why is this a long term goal? Start today.


-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between now
and then, and even when we're at the final state there will be need to
have some sort of sandbox for development and test of future bindings.


Why not just set up a git tree right away?


Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time are
nothing but pain, but we're arguing that in circles anyway.


No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up as
we go along.


We have currently a lot of broken bindings, because people didn't know how
to define ones and those they defined have not been properly reviewed. Do
you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable and
well they probably are already de facto stable. This is mostly about
subsystem bindings and whatever already has many users, both made them get
more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply broken.
Take max8925 backlight driver, that Olof started this whole discussion
with, as an example. We need to sort them out before they can be
stabilized.


That is a nice summary of how we got from null to now and Richard seems 
to be simply saying: let's stop mucking about and make this a project 
with a well-defined process of dealing with staging and stable bindings 
and keep stable bindings stable. Whether it should be within the kernel 
repo as a separate subsystem or in an entire different repo is a trivial 
decision, but still a decision that needs to be made.


Apart from stable DT bindings I would love to see a DT compiler that 
that next to DT syntax detects mistakes in properties used for the 
selfish reason that I spent hours debugging regulator code, because I 
typed vmmc_supply iso vmmc-supply. I did not go through all the 
bindings, but this may require a more formal description so it could be 
compiled/read in the DT compiler.


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 11:51 AM, Tomasz Figa wrote:

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:

Long term, final goal is likely to be close to what Russell is saying


Why is this a long term goal? Start today.


-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between now
and then, and even when we're at the final state there will be need to
have some sort of sandbox for development and test of future bindings.


Why not just set up a git tree right away?


Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time are
nothing but pain, but we're arguing that in circles anyway.


No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up as
we go along.


We have currently a lot of broken bindings, because people didn't know how
to define ones and those they defined have not been properly reviewed. Do
you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable and
well they probably are already de facto stable. This is mostly about
subsystem bindings and whatever already has many users, both made them get
more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply broken.
Take max8925 backlight driver, that Olof started this whole discussion
with, as an example. We need to sort them out before they can be
stabilized.


That is a nice summary of how we got from null to now and Richard seems 
to be simply saying: let's stop mucking about and make this a project 
with a well-defined process of dealing with staging and stable bindings 
and keep stable bindings stable. Whether it should be within the kernel 
repo as a separate subsystem or in an entire different repo is a trivial 
decision, but still a decision that needs to be made.


Apart from stable DT bindings I would love to see a DT compiler that 
that next to DT syntax detects mistakes in properties used for the 
selfish reason that I spent hours debugging regulator code, because I 
typed vmmc_supply iso vmmc-supply. I did not go through all the 
bindings, but this may require a more formal description so it could be 
compiled/read in the DT compiler.


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 12:24 PM, Arend van Spriel wrote:

On 07/27/2013 11:51 AM, Tomasz Figa wrote:

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:

Long term, final goal is likely to be close to what Russell is saying


Why is this a long term goal? Start today.


-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between now
and then, and even when we're at the final state there will be need to
have some sort of sandbox for development and test of future bindings.


Why not just set up a git tree right away?


Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time are
nothing but pain, but we're arguing that in circles anyway.


No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up as
we go along.


We have currently a lot of broken bindings, because people didn't know
how
to define ones and those they defined have not been properly reviewed. Do
you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable and
well they probably are already de facto stable. This is mostly about
subsystem bindings and whatever already has many users, both made them
get
more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply broken.
Take max8925 backlight driver, that Olof started this whole discussion
with, as an example. We need to sort them out before they can be
stabilized.


That is a nice summary of how we got from null to now and Richard seems
to be simply saying: let's stop mucking about and make this a project
with a well-defined process of dealing with staging and stable bindings
and keep stable bindings stable. Whether it should be within the kernel
repo as a separate subsystem or in an entire different repo is a trivial
decision, but still a decision that needs to be made.

Apart from stable DT bindings I would love to see a DT compiler that
that next to DT syntax detects mistakes in properties used for the
selfish reason that I spent hours debugging regulator code, because I
typed vmmc_supply iso vmmc-supply. I did not go through all the
bindings, but this may require a more formal description so it could be
compiled/read in the DT compiler.


Oh, and the reason for my tinkering on dts is here:

http://mid.gmane.org/51e7aa24.6080...@broadcom.com

Happily using Pandaboard for my driver testing and than *kaboom*. 
board-omap4panda.c is gone although the device tree does not provide the 
same functionality. Of course, this is not about DT bindings.


Regards,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Ksummit-2013-discuss] DT bindings as ABI [was: Do we have people interested in device tree janitoring / cleanup?]

[Arend van Spriel]

On 07/27/2013 12:36 PM, Tomasz Figa wrote:

On Saturday 27 of July 2013 12:24:24 Arend van Spriel wrote:

On 07/27/2013 11:51 AM, Tomasz Figa wrote:

On Saturday 27 of July 2013 07:04:08 Richard Cochran wrote:

On Fri, Jul 26, 2013 at 08:49:43AM -0700, Olof Johansson wrote:

Long term, final goal is likely to be close to what Russell is
saying


Why is this a long term goal? Start today.


-- nothing should go into the kernel tree unless the binding is in a
fully stable state. However, we have a transitional period between
now
and then, and even when we're at the final state there will be need
to
have some sort of sandbox for development and test of future
bindings.


Why not just set up a git tree right away?


Dealing with all that, as well as the actual process for locking in
bindings, is what needs to be sorted out.

I think we're all in agreement that bindings that change over time
are
nothing but pain, but we're arguing that in circles anyway.


No.

I keep saying, the bindings must be stable ABI, *today*.

You keep saying, maybe later, but until then we will make things up
as
we go along.


We have currently a lot of broken bindings, because people didn't know
how to define ones and those they defined have not been properly
reviewed. Do you really want such broken ABI in the kernel?

Sure, there are many existing bindings that can be just made stable
and
well they probably are already de facto stable. This is mostly about
subsystem bindings and whatever already has many users, both made them
get more thought when designing and more review before merging.

Still, a lot of device and platform-specific bindings are simply
broken. Take max8925 backlight driver, that Olof started this whole
discussion with, as an example. We need to sort them out before they
can be stabilized.


That is a nice summary of how we got from null to now and Richard seems
to be simply saying: let's stop mucking about and make this a project
with a well-defined process of dealing with staging and stable bindings
and keep stable bindings stable. Whether it should be within the kernel
repo as a separate subsystem or in an entire different repo is a trivial
decision, but still a decision that needs to be made.


Yes, basically that's our current situation.

Still, I would disagree about the decision being trivial, as each choice
will have further, and likely pretty significant, consequences on binding
maintenance, submission, review and for dependent things, like drivers or
platforms using such bindings. This needs to be discussed enough.


Apart from stable DT bindings I would love to see a DT compiler that
that next to DT syntax detects mistakes in properties used for the
selfish reason that I spent hours debugging regulator code, because I
typed vmmc_supply iso vmmc-supply. I did not go through all the
bindings, but this may require a more formal description so it could be
compiled/read in the DT compiler.


This bothered me as well and that's why I'm working on this. I still can't
get myself to write a very long mail (I'm more a coder than writer...)
about the whole idea, my proposal of how it could look and problems we
need to solve, but I'll try better this evening.


Let's see how many people go and scream if I say this: Too bad .dts 
files are not done using XML format as DT bindings could be described 
using XML Schema.


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()

[Arend van Spriel]

On 07/26/2013 03:03 PM, Steven Rostedt wrote:

From: "Steven Rostedt (Red Hat)"

Commit a82274151af "tracing: Protect ftrace_trace_arrays list in trace_events.c"
added taking the trace_types_lock mutex in trace_events.c as there were
several locations that needed it for protection. Unfortunately, it also
encapsulated a call to tracing_reset_all_online_cpus() which also takes
the trace_types_lock, causing a deadlock.

This happens when a module has tracepoints and has been traced. When the
module is removed, the trace events module notifier will grab the
trace_types_lock, do a bunch of clean ups, and also clears the buffer
by calling tracing_reset_all_online_cpus. This doesn't happen often
which explains why it wasn't caught right away.

Commit a82274151af was marked for stable, which means this must be
sent to stable too.

Link:http://lkml.kernel.org/r/51eec646.7070...@broadcom.com

Reported-by: Arend van *Spril*


Nasty dutch names, huh. If we ever meet on a summit you may try to 
pronounce it :-) Way easier than Finnish.


Regards,
Arend


Tested-by: Arend van *Spriel*
Cc: Alexander Z Lam
Cc: Vaibhav Nagarnaik
Cc: David Sharp
Cc:sta...@vger.kernel.org  # 3.10
Signed-off-by: Steven Rostedt
---
  kernel/trace/trace.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 12:37 PM, Roger Quadros wrote:

On 07/26/2013 01:23 PM, Arend van Spriel wrote:

On 07/26/2013 12:15 PM, Arend van Spriel wrote:

On 07/26/2013 12:13 PM, Arend van Spriel wrote:

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on
omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y


Aaargh. Missing this one. Will retry.


Yes. That is working although it seems I don't need the MUSB stuff.


MUSB is required for the micro OTG port and not USB host ports.


Roger that (apologies for my corny sense of humor).


cheers,
-roger





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 12:15 PM, Arend van Spriel wrote:

On 07/26/2013 12:13 PM, Arend van Spriel wrote:

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on
omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y


Aaargh. Missing this one. Will retry.


Yes. That is working although it seems I don't need the MUSB stuff.

Regards,
Arend


CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_HCD_OMAP=y


Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y


Here are the results of the dutch jury ;-)

[2.537109] HS USB OTG: no transceiver configured
[2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
[2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral

I am surely missing something here. Either in device tree or .config.

Regards,
Arend





--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 12:13 PM, Arend van Spriel wrote:

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y


Aaargh. Missing this one. Will retry.


CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_HCD_OMAP=y


Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y


Here are the results of the dutch jury ;-)

[2.537109] HS USB OTG: no transceiver configured
[2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
[2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral

I am surely missing something here. Either in device tree or .config.

Regards,
Arend



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_HCD_OMAP=y


Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y



I will compare this with my .config. At first glance it looks like I am 
missing some of these.


Gr. AvS

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_HCD_OMAP=y


Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y



I will compare this with my .config. At first glance it looks like I am 
missing some of these.


Gr. AvS

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 12:13 PM, Arend van Spriel wrote:

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y


Aaargh. Missing this one. Will retry.


CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_HCD_OMAP=y


Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y


Here are the results of the dutch jury ;-)

[2.537109] HS USB OTG: no transceiver configured
[2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
[2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral

I am surely missing something here. Either in device tree or .config.

Regards,
Arend



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 12:15 PM, Arend van Spriel wrote:

On 07/26/2013 12:13 PM, Arend van Spriel wrote:

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on
omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y


Aaargh. Missing this one. Will retry.


Yes. That is working although it seems I don't need the MUSB stuff.

Regards,
Arend


CONFIG_USB_OHCI_HCD=y
CONFIG_USB_EHCI_HCD_OMAP=y


Sorry I missed saying I also set had to set CONFIG_NOP_USB_XCEIV=y


Here are the results of the dutch jury ;-)

[2.537109] HS USB OTG: no transceiver configured
[2.542541] musb-hdrc musb-hdrc.0.auto: musb_init_controller failed
with status -517
[2.542541] platform musb-hdrc.0.auto: Driver musb-hdrc requests
probe deferral

I am surely missing something here. Either in device tree or .config.

Regards,
Arend





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/26/2013 12:37 PM, Roger Quadros wrote:

On 07/26/2013 01:23 PM, Arend van Spriel wrote:

On 07/26/2013 12:15 PM, Arend van Spriel wrote:

On 07/26/2013 12:13 PM, Arend van Spriel wrote:

On 07/26/2013 05:00 AM, Joel Fernandes wrote:

On 07/25/2013 09:49 PM, Joel Fernandes wrote:

[..]


Can I get back on this topic. When USB and ethernet was working for me
as stated above, I was not doing tftpboot. When I use tftpboot the
images are obtained from the tftp server, but after kernel has started
there is nothing in /sys/bus/usb/devices/.


I quickly tried 3.11-rc2 + Roger's USB PHY clock patch on
omap4-panda-es
and enabled following USB options:

CONFIG_USB_MUSB_HDRC=y
CONFIG_USB_PHY=y
CONFIG_OMAP_USB2=y
CONFIG_OMAP_CONTROL_USB=y
CONFIG_USB_MUSB_OMAP2PLUS=y
CONFIG_MFD_OMAP_USB_HOST=y
CONFIG_USB_EHCI_HCD=y


Aaargh. Missing this one. Will retry.


Yes. That is working although it seems I don't need the MUSB stuff.


MUSB is required for the micro OTG port and not USB host ports.


Roger that (apologies for my corny sense of humor).


cheers,
-roger





--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 9/9] tracing: Remove locking trace_types_lock from tracing_reset_all_online_cpus()

[Arend van Spriel]

On 07/26/2013 03:03 PM, Steven Rostedt wrote:

From: Steven Rostedt (Red Hat)rost...@goodmis.org

Commit a82274151af tracing: Protect ftrace_trace_arrays list in trace_events.c
added taking the trace_types_lock mutex in trace_events.c as there were
several locations that needed it for protection. Unfortunately, it also
encapsulated a call to tracing_reset_all_online_cpus() which also takes
the trace_types_lock, causing a deadlock.

This happens when a module has tracepoints and has been traced. When the
module is removed, the trace events module notifier will grab the
trace_types_lock, do a bunch of clean ups, and also clears the buffer
by calling tracing_reset_all_online_cpus. This doesn't happen often
which explains why it wasn't caught right away.

Commit a82274151af was marked for stable, which means this must be
sent to stable too.

Link:http://lkml.kernel.org/r/51eec646.7070...@broadcom.com

Reported-by: Arend van *Spril*ar...@broadcom.com


Nasty dutch names, huh. If we ever meet on a summit you may try to 
pronounce it :-) Way easier than Finnish.


Regards,
Arend


Tested-by: Arend van *Spriel*ar...@broadcom.com
Cc: Alexander Z Lama...@google.com
Cc: Vaibhav Nagarnaikvnagarn...@google.com
Cc: David Sharpdhsh...@google.com
Cc:sta...@vger.kernel.org  # 3.10
Signed-off-by: Steven Rostedtrost...@goodmis.org
---
  kernel/trace/trace.c |3 +--
  1 file changed, 1 insertion(+), 2 deletions(-)



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT DTS file

[Arend van Spriel]

On 07/25/2013 05:43 PM, Tim Kryger wrote:

On Mon, Jul 22, 2013 at 9:57 AM, Christian Daudt  wrote:


it'd be nice to have something to point
people to as this being the best practice for kernel dev.


Power.org's ePAPR exclusively omits the 0x in the unit-address of node names.

https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf



Thanks for the link. While browsing on power.org I got the impression 
that I needed to have a membership to get it.


Regards,
Arend

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 02:42 PM, Roger Quadros wrote:

On 07/18/2013 03:38 PM, Arend van Spriel wrote:

On 07/18/2013 01:30 PM, Roger Quadros wrote:

On 07/18/2013 02:24 PM, Arend van Spriel wrote:

On 07/18/2013 01:18 PM, Roger Quadros wrote:

Hi Arend,

On 07/18/2013 11:41 AM, Arend van Spriel wrote:

Hi Tony,


We are using the panda board (es variant) for testing our SDIO based chips. For 
this we have an adapter card connection to expansion connector A. As this 
adapter is not publicly available we had internally patched board-omap4panda.c. 
Also we follow the -rc releases and use TFTP to boot the kernel image which 
requires USB.

Moving to 3.11-rc1 I found that the mentioned board file was removed by your 
commit:

commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren 
Date:   Thu May 30 12:53:05 2013 -0700

   ARM: OMAP2+: Remove board-omap4panda.c

As our patches on that file are internal I do not hold it against you. This is 
no regression and we need to fix it.

So my first step was to follow the recipe given in that commit. Beside that I 
noticed a thread about USB issue on LKML so I also applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros 
Date:   Tue Jun 18 19:04:47 2013 +0300

   ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is picked up by 
the kernel, but the USB does not seem very active. No ethernet connectivity. 
This does seem a regression to me. Is there some other patch that I need to get 
it going again?



I tried with your config and 3.11-rc1 kernel with the above commit on top and 
ethernet seems to
work for me. My boot log is attached.

Are you sure that you are building the DTB for panda-es and the bootloader is 
picking up the right file and
not an outdated one?


I appended the DTB to the kernel image thus avoiding the need to update u-boot 
(at least that is what I understood from Tony's commit).



I understand this can be a little tedious at first.

This is my u-boot boot.txt

fatload mmc 0:1 0x825f omap4-panda-es.dtb
fatload mmc 0:1 0x8030 uImage
set fdt_high 0x
setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 
rootwait
bootm 0x8030 - 0x825f

You need to generate boot.scr from the above boot.txt and place it in SD card 
boot partition.

mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr

And of course copy the omap4-panda-es.dtb to SD card boot partition.

hope this helps.


Thanks for sharing this.


Why is the version of SPL loader and u-boot different in your log?
You need to use the MLO file generated by the u-boot build along with the 
uImage.

Just to be sure we are on the same setup could you please try with latest 
u-boot release (2013-04). Thanks.


I recall having difficulty with TFTP boot using a 2013 u-boot release, but that 
hurdle is for later. I will try.



OK. We can figure this out as well.


I tried with same SPL and u-boot version, but that did not work out. So I moved 
to v2013.04 and the log looks better. I was especially interested in this:

[2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap
[2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0
[2.958770] smsc95xx v1.0.4
Starting logging: OK
Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0


Cool! :).

FYI. I also tested tftpboot from u-boot and NFS root file system and it works 
fine.


Hi Roger,

Can I get back on this topic. When USB and ethernet was working for me 
as stated above, I was not doing tftpboot. When I use tftpboot the 
images are obtained from the tftp server, but after kernel has started 
there is nothing in /sys/bus/usb/devices/.


I tried a 'usb stop' before booting the kernel, but that does not help 
either. As you stated to have tftpboot working, maybe you can help me.


Regards,
Arend



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression 3.11-rc1: rmmod hangs after tracing module

[Arend van Spriel]

On 07/23/2013 08:44 PM, Steven Rostedt wrote:

On Tue, 2013-07-23 at 20:07 +0200, Arend van Spriel wrote:

Hi Steven,

During testing of our brcmfmac wireless driver I had a trace-cmd running
along (trace-cmd record -e brcmfmac:*). After the test I stopped the
trace, unplugged my usb device and did a rmmod resulting in the attached
lockdep splat. Hope you have an idea what is going wrong here.


Thanks for the report!

Does this fix you bug?


Thanks Steve,

Tested your patch and it indeed fixes my deadlock.

Regards,
Arend


-- Steve

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 69cba47..882ec1d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1224,18 +1224,17 @@ void tracing_reset_current(int cpu)
tracing_reset(_trace.trace_buffer, cpu);
  }

+/* Must have trace_types_lock held */
  void tracing_reset_all_online_cpus(void)
  {
struct trace_array *tr;

-   mutex_lock(_types_lock);
list_for_each_entry(tr, _trace_arrays, list) {
tracing_reset_online_cpus(>trace_buffer);
  #ifdef CONFIG_TRACER_MAX_TRACE
tracing_reset_online_cpus(>max_buffer);
  #endif
}
-   mutex_unlock(_types_lock);
  }

  #define SAVED_CMDLINES 128






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: regression 3.11-rc1: rmmod hangs after tracing module

[Arend van Spriel]

On 07/23/2013 08:44 PM, Steven Rostedt wrote:

On Tue, 2013-07-23 at 20:07 +0200, Arend van Spriel wrote:

Hi Steven,

During testing of our brcmfmac wireless driver I had a trace-cmd running
along (trace-cmd record -e brcmfmac:*). After the test I stopped the
trace, unplugged my usb device and did a rmmod resulting in the attached
lockdep splat. Hope you have an idea what is going wrong here.


Thanks for the report!

Does this fix you bug?


Thanks Steve,

Tested your patch and it indeed fixes my deadlock.

Regards,
Arend


-- Steve

diff --git a/kernel/trace/trace.c b/kernel/trace/trace.c
index 69cba47..882ec1d 100644
--- a/kernel/trace/trace.c
+++ b/kernel/trace/trace.c
@@ -1224,18 +1224,17 @@ void tracing_reset_current(int cpu)
tracing_reset(global_trace.trace_buffer, cpu);
  }

+/* Must have trace_types_lock held */
  void tracing_reset_all_online_cpus(void)
  {
struct trace_array *tr;

-   mutex_lock(trace_types_lock);
list_for_each_entry(tr, ftrace_trace_arrays, list) {
tracing_reset_online_cpus(tr-trace_buffer);
  #ifdef CONFIG_TRACER_MAX_TRACE
tracing_reset_online_cpus(tr-max_buffer);
  #endif
}
-   mutex_unlock(trace_types_lock);
  }

  #define SAVED_CMDLINES 128






--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 02:42 PM, Roger Quadros wrote:

On 07/18/2013 03:38 PM, Arend van Spriel wrote:

On 07/18/2013 01:30 PM, Roger Quadros wrote:

On 07/18/2013 02:24 PM, Arend van Spriel wrote:

On 07/18/2013 01:18 PM, Roger Quadros wrote:

Hi Arend,

On 07/18/2013 11:41 AM, Arend van Spriel wrote:

Hi Tony,


We are using the panda board (es variant) for testing our SDIO based chips. For 
this we have an adapter card connection to expansion connector A. As this 
adapter is not publicly available we had internally patched board-omap4panda.c. 
Also we follow the -rc releases and use TFTP to boot the kernel image which 
requires USB.

Moving to 3.11-rc1 I found that the mentioned board file was removed by your 
commit:

commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren t...@atomide.com
Date:   Thu May 30 12:53:05 2013 -0700

   ARM: OMAP2+: Remove board-omap4panda.c

As our patches on that file are internal I do not hold it against you. This is 
no regression and we need to fix it.

So my first step was to follow the recipe given in that commit. Beside that I 
noticed a thread about USB issue on LKML so I also applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros rog...@ti.com
Date:   Tue Jun 18 19:04:47 2013 +0300

   ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is picked up by 
the kernel, but the USB does not seem very active. No ethernet connectivity. 
This does seem a regression to me. Is there some other patch that I need to get 
it going again?



I tried with your config and 3.11-rc1 kernel with the above commit on top and 
ethernet seems to
work for me. My boot log is attached.

Are you sure that you are building the DTB for panda-es and the bootloader is 
picking up the right file and
not an outdated one?


I appended the DTB to the kernel image thus avoiding the need to update u-boot 
(at least that is what I understood from Tony's commit).



I understand this can be a little tedious at first.

This is my u-boot boot.txt

fatload mmc 0:1 0x825f omap4-panda-es.dtb
fatload mmc 0:1 0x8030 uImage
set fdt_high 0x
setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 
rootwait
bootm 0x8030 - 0x825f

You need to generate boot.scr from the above boot.txt and place it in SD card 
boot partition.

mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr

And of course copy the omap4-panda-es.dtb to SD card boot partition.

hope this helps.


Thanks for sharing this.


Why is the version of SPL loader and u-boot different in your log?
You need to use the MLO file generated by the u-boot build along with the 
uImage.

Just to be sure we are on the same setup could you please try with latest 
u-boot release (2013-04). Thanks.


I recall having difficulty with TFTP boot using a 2013 u-boot release, but that 
hurdle is for later. I will try.



OK. We can figure this out as well.


I tried with same SPL and u-boot version, but that did not work out. So I moved 
to v2013.04 and the log looks better. I was especially interested in this:

[2.807434] usb 1-1.1: new high-speed USB device number 3 using ehci-omap
[2.932495] usb 1-1.1: New USB device found, idVendor=0424, idProduct=ec00
[2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, SerialNumbe0
[2.958770] smsc95xx v1.0.4
Starting logging: OK
Initializing random number generator... [3.045806] smsc95xx 1-1.1:1.0 eth0


Cool! :).

FYI. I also tested tftpboot from u-boot and NFS root file system and it works 
fine.


Hi Roger,

Can I get back on this topic. When USB and ethernet was working for me 
as stated above, I was not doing tftpboot. When I use tftpboot the 
images are obtained from the tftp server, but after kernel has started 
there is nothing in /sys/bus/usb/devices/.


I tried a 'usb stop' before booting the kernel, but that does not help 
either. As you stated to have tftpboot working, maybe you can help me.


Regards,
Arend



--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT DTS file

[Arend van Spriel]

On 07/25/2013 05:43 PM, Tim Kryger wrote:

On Mon, Jul 22, 2013 at 9:57 AM, Christian Daudt c...@broadcom.com wrote:


it'd be nice to have something to point
people to as this being the best practice for kernel dev.


Power.org's ePAPR exclusively omits the 0x in the unit-address of node names.

https://www.power.org/wp-content/uploads/2012/06/Power_ePAPR_APPROVED_v1.1.pdf



Thanks for the link. While browsing on power.org I got the impression 
that I needed to have a membership to get it.


Regards,
Arend

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

regression 3.11-rc1: rmmod hangs after tracing module

[Arend van Spriel]

Hi Steven,

During testing of our brcmfmac wireless driver I had a trace-cmd running 
along (trace-cmd record -e brcmfmac:*). After the test I stopped the 
trace, unplugged my usb device and did a rmmod resulting in the attached 
lockdep splat. Hope you have an idea what is going wrong here.


Regards,
Arend
Jul 23 16:05:00 arend-lp-dev kernel: [23055.298412] usbcore: deregistering 
interface driver brcmfmac
Jul 23 16:05:00 arend-lp-dev kernel: [23055.304526] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.306019] 
=
Jul 23 16:05:00 arend-lp-dev kernel: [23055.311417] [ INFO: possible recursive 
locking detected ]
Jul 23 16:05:00 arend-lp-dev kernel: [23055.316812] 
3.11.0-rc1-wl-testing-lockdep-2-g41cc093-dirty #1 Tainted: GW  O
Jul 23 16:05:00 arend-lp-dev kernel: [23055.324893] 
-
Jul 23 16:05:00 arend-lp-dev kernel: [23055.330289] rmmod/3345 is trying to 
acquire lock:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.334989]  
(trace_types_lock){+.+.+.}, at: [] 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.343921] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.343921] but task is already holding 
lock:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.349751]  
(trace_types_lock){+.+.+.}, at: [] trace_module_notify+0x19/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353445] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353445] other info that might help 
us debug this:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353446]  Possible unsafe locking 
scenario:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353446] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353447]CPU0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353448]
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353450]   lock(trace_types_lock);
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353451]   lock(trace_types_lock);
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353452] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353452]  *** DEADLOCK ***
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353452] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353453]  May be due to missing lock 
nesting notation
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353453] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353454] 3 locks held by rmmod/3345:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353464]  #0:  
((module_notify_list).rwsem){.+.+.+}, at: [] 
__blocking_notifier_call_chain+0x2a/0x70
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353469]  #1:  
(trace_types_lock){+.+.+.}, at: [] trace_module_notify+0x19/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353474]  #2:  
(event_mutex){+.+.+.}, at: [] trace_module_notify+0x25/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353475] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353475] stack backtrace:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353479] CPU: 3 PID: 3345 Comm: 
rmmod Tainted: GW  O 3.11.0-rc1-wl-testing-lockdep-2-g41cc093-dirty 
#1
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353480] Hardware name: Dell Inc. 
Latitude E6410/07XJP9, BIOS A07 02/15/2011
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353486]    e2659dd4 
c1522e3d c1a3b010 e2659e50 c109ee33 c16b70b5
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353492]  e1603890 0d11 c1a3d320 
e1603a50 bc1d806f 0003 e1603a80 00011781
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353497]  bc1d806f c18d8e00  
c1a3b010  00011781 e16035a0 e16035a0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353498] Call Trace:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353504]  [] 
dump_stack+0x4b/0x66
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353510]  [] 
__lock_acquire+0x14a3/0x19d0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353515]  [] ? 
mark_held_locks+0x68/0x110
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353518]  [] ? 
mark_held_locks+0x68/0x110
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353522]  [] 
lock_acquire+0x79/0x110
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353526]  [] ? 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353531]  [] 
mutex_lock_nested+0x66/0x350
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353535]  [] ? 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353540]  [] ? 
kfree+0x18f/0x1a0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353543]  [] ? 
trace_module_notify+0x25c/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353547]  [] 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353550]  [] 
trace_module_notify+0x26b/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353555]  [] 
notifier_call_chain+0x45/0x60
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353559]  [] 
__blocking_notifier_call_chain+0x43/0x70
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353576]  [] ? 
brcmf_usb_ctlwrite_complete+0x90/0x90 [brcmfmac]
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353580]  [] 

regression 3.11-rc1: rmmod hangs after tracing module

[Arend van Spriel]

Hi Steven,

During testing of our brcmfmac wireless driver I had a trace-cmd running 
along (trace-cmd record -e brcmfmac:*). After the test I stopped the 
trace, unplugged my usb device and did a rmmod resulting in the attached 
lockdep splat. Hope you have an idea what is going wrong here.


Regards,
Arend
Jul 23 16:05:00 arend-lp-dev kernel: [23055.298412] usbcore: deregistering 
interface driver brcmfmac
Jul 23 16:05:00 arend-lp-dev kernel: [23055.304526] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.306019] 
=
Jul 23 16:05:00 arend-lp-dev kernel: [23055.311417] [ INFO: possible recursive 
locking detected ]
Jul 23 16:05:00 arend-lp-dev kernel: [23055.316812] 
3.11.0-rc1-wl-testing-lockdep-2-g41cc093-dirty #1 Tainted: GW  O
Jul 23 16:05:00 arend-lp-dev kernel: [23055.324893] 
-
Jul 23 16:05:00 arend-lp-dev kernel: [23055.330289] rmmod/3345 is trying to 
acquire lock:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.334989]  
(trace_types_lock){+.+.+.}, at: [c10df3a0] 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.343921] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.343921] but task is already holding 
lock:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.349751]  
(trace_types_lock){+.+.+.}, at: [c10ef799] trace_module_notify+0x19/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353445] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353445] other info that might help 
us debug this:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353446]  Possible unsafe locking 
scenario:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353446] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353447]CPU0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353448]
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353450]   lock(trace_types_lock);
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353451]   lock(trace_types_lock);
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353452] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353452]  *** DEADLOCK ***
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353452] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353453]  May be due to missing lock 
nesting notation
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353453] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353454] 3 locks held by rmmod/3345:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353464]  #0:  
((module_notify_list).rwsem){.+.+.+}, at: [c10683da] 
__blocking_notifier_call_chain+0x2a/0x70
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353469]  #1:  
(trace_types_lock){+.+.+.}, at: [c10ef799] trace_module_notify+0x19/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353474]  #2:  
(event_mutex){+.+.+.}, at: [c10ef7a5] trace_module_notify+0x25/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353475] 
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353475] stack backtrace:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353479] CPU: 3 PID: 3345 Comm: 
rmmod Tainted: GW  O 3.11.0-rc1-wl-testing-lockdep-2-g41cc093-dirty 
#1
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353480] Hardware name: Dell Inc. 
Latitude E6410/07XJP9, BIOS A07 02/15/2011
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353486]    e2659dd4 
c1522e3d c1a3b010 e2659e50 c109ee33 c16b70b5
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353492]  e1603890 0d11 c1a3d320 
e1603a50 bc1d806f 0003 e1603a80 00011781
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353497]  bc1d806f c18d8e00  
c1a3b010  00011781 e16035a0 e16035a0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353498] Call Trace:
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353504]  [c1522e3d] 
dump_stack+0x4b/0x66
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353510]  [c109ee33] 
__lock_acquire+0x14a3/0x19d0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353515]  [c10a0038] ? 
mark_held_locks+0x68/0x110
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353518]  [c10a0038] ? 
mark_held_locks+0x68/0x110
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353522]  [c109f8b9] 
lock_acquire+0x79/0x110
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353526]  [c10df3a0] ? 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353531]  [c1524b06] 
mutex_lock_nested+0x66/0x350
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353535]  [c10df3a0] ? 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353540]  [c113e2df] ? 
kfree+0x18f/0x1a0
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353543]  [c10ef9dc] ? 
trace_module_notify+0x25c/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353547]  [c10df3a0] 
tracing_reset_all_online_cpus+0x10/0x50
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353550]  [c10ef9eb] 
trace_module_notify+0x26b/0x270
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353555]  [c152d655] 
notifier_call_chain+0x45/0x60
Jul 23 16:05:00 arend-lp-dev kernel: [23055.353559]  [c10683f3] 
__blocking_notifier_call_chain+0x43/0x70
Jul 23 16:05:00 

Re: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT DTS file

[Arend van Spriel]

On 07/22/2013 03:38 PM, Lee Jones wrote:

On Mon, 22 Jul 2013, Christian Daudt wrote:


On 13-07-22 03:52 AM, Lee Jones wrote:

Cc: Christian Daudt 
Signed-off-by: Lee Jones 
---
  arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351-brt.dts 
b/arch/arm/boot/dts/bcm11351-brt.dts
index 67ec524..fdace5d 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -27,18 +27,18 @@
status = "okay";
};
-   sdio0: sdio@0x3f18 {
+   sdio0: sdio@3f18 {
max-frequency = <4800>;
status = "okay";
};
-   sdio1: sdio@0x3f19 {
+   sdio1: sdio@3f19 {
non-removable;
max-frequency = <4800>;
status = "okay";
};
-   sdio3: sdio@0x3f1b {
+   sdio3: sdio@3f1b {
max-frequency = <4800>;
status = "okay";
};

Hi Lee,
  Is this convention documented ? Someone called my attention to the
fact that this dts files was inconsistent in its use of 0x in names,
but I was not aware of a coding guideline for this.


The best two places I can think of are:

Documentation/devicetree/usage-model.txt
and
http://www.devicetree.org/Device_Tree_Usage


And even those do not stick to a single convention, but that is what can 
be expected of a twiki page :-p


Regards,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 05/22] ARM: dts: bcm281xx: Remove '0x's from BCM11351 BRT DTS file

[Arend van Spriel]

On 07/22/2013 03:38 PM, Lee Jones wrote:

On Mon, 22 Jul 2013, Christian Daudt wrote:


On 13-07-22 03:52 AM, Lee Jones wrote:

Cc: Christian Daudt c...@broadcom.com
Signed-off-by: Lee Jones lee.jo...@linaro.org
---
  arch/arm/boot/dts/bcm11351-brt.dts | 6 +++---
  1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm/boot/dts/bcm11351-brt.dts 
b/arch/arm/boot/dts/bcm11351-brt.dts
index 67ec524..fdace5d 100644
--- a/arch/arm/boot/dts/bcm11351-brt.dts
+++ b/arch/arm/boot/dts/bcm11351-brt.dts
@@ -27,18 +27,18 @@
status = okay;
};
-   sdio0: sdio@0x3f18 {
+   sdio0: sdio@3f18 {
max-frequency = 4800;
status = okay;
};
-   sdio1: sdio@0x3f19 {
+   sdio1: sdio@3f19 {
non-removable;
max-frequency = 4800;
status = okay;
};
-   sdio3: sdio@0x3f1b {
+   sdio3: sdio@3f1b {
max-frequency = 4800;
status = okay;
};

Hi Lee,
  Is this convention documented ? Someone called my attention to the
fact that this dts files was inconsistent in its use of 0x in names,
but I was not aware of a coding guideline for this.


The best two places I can think of are:

Documentation/devicetree/usage-model.txt
and
http://www.devicetree.org/Device_Tree_Usage


And even those do not stick to a single convention, but that is what can 
be expected of a twiki page :-p


Regards,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: brcm80211: machine freezing hard with rfkill on

[Arend van Spriel]

On 07/19/13 09:02, Jiri Slaby wrote:

Hi,

our users report [1] that their machines freeze hard when they have
rfkill turned on and try to run wpa_supplicant or enable network
otherwise. This is with BCM43225 over PCI chip.

Any ideas what that could be or how to fix this?

[1] https://bugzilla.novell.com/show_bug.cgi?id=787649

thanks,


Hi Jiri,

Looking in the bug report it seems to be on 3.4 kernel. The commit below 
is done later.


Regards,
Arend
---
commit 82d8eba358badb466a4e988ecabf0668a8d92e9c
Author: Piotr Haber 
Date:   Wed Sep 19 22:21:15 2012 +0200

brcmsmac: don't start device when RfKill is engaged

This patch fixes a bug when device is being started
while RfKill switch is engaged, leading to hang
due to partial initialization of hardware.

Tested-by: 
Reviewed-by: Arend van Spriel 
Reviewed-by: Hante Meuleman 
Signed-off-by: Piotr Haber 
Signed-off-by: Arend van Spriel 
Signed-off-by: John W. Linville 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I do have a 
question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an 
explanation to it and it would help my understanding to know where this 
difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h for 
pmx_core registers.


That was what I was looking for. Thanks!


NOTE: omap4_pmx_wkup starts at a different address. Those are for wakeup domain
control registers.


Will keep that in mind.

Regards,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I do 
have a question. Among other things the patch adds these dt entries.


+   0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | 
MODE0 */
+   0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | 
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:	OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:	OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),


and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET   0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET   0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is 
probably an explanation to it and it would help my understanding to know 
where this difference comes from. Hope you can help me out here.


Below are the definitions that I need to move into a dts.

Regards,
Arend

/* MMC2 Mux for extension board */
/* MMC2 CMD */
OMAP4_MUX(GPMC_NWE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
/* MMC2 CLK */
OMAP4_MUX(GPMC_NOE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
/* MMC2 DAT 0-7 */
OMAP4_MUX(GPMC_AD0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(GPMC_AD1, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(GPMC_AD2, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(GPMC_AD3, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I do 
have a question. Among other things the patch adds these dt entries.


+   0x108 0x118 /* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | 
MODE0 */
+   0x10a 0x118 /* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | 
MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:	OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:	OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),


and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET   0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET   0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is 
probably an explanation to it and it would help my understanding to know 
where this difference comes from. Hope you can help me out here.


Below are the definitions that I need to move into a dts.

Regards,
Arend

/* MMC2 Mux for extension board */
/* MMC2 CMD */
OMAP4_MUX(GPMC_NWE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
/* MMC2 CLK */
OMAP4_MUX(GPMC_NOE, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
/* MMC2 DAT 0-7 */
OMAP4_MUX(GPMC_AD0, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(GPMC_AD1, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(GPMC_AD2, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),
OMAP4_MUX(GPMC_AD3, OMAP_MUX_MODE1 | OMAP_PIN_INPUT_PULLUP),

--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/19/2013 12:49 PM, Roger Quadros wrote:

On 07/19/2013 01:36 PM, Arend van Spriel wrote:

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#


I have been looking at the pandaboard patch in the series above and I do have a 
question. Among other things the patch adds these dt entries.

+0x108 0x118/* sdmmc5_clk.sdmmc5_clk INPUT_PULLUP | MODE0 */
+0x10a 0x118/* sdmmc5_cmd.sdmmc5_cmd INPUT_PULLUP | MODE0 */

If I look at the similar names in the deceased board-omap4panda.c:

board-omap4panda.c:OMAP4_MUX(SDMMC5_CMD, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),
board-omap4panda.c:OMAP4_MUX(SDMMC5_CLK, OMAP_MUX_MODE0 | 
OMAP_PIN_INPUT_PULLUP),

and in mux44xx.h:

mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CLK_OFFSET0x0148
mux44xx.h:#define OMAP4_CTRL_MODULE_PAD_SDMMC5_CMD_OFFSET0x014a

So how did 0x0148 get 0x0108 in DT and 0x014a get 0x010a. There is probably an 
explanation to it and it would help my understanding to know where this 
difference comes from. Hope you can help me out here.



If you see omap4.dtsi, omap4_pmx_core starts at register address 0x4a100040.

So, you need to subtract 0x40 from the offsets defined in mux44xx.h for 
pmx_core registers.


That was what I was looking for. Thanks!


NOTE: omap4_pmx_wkup starts at a different address. Those are for wakeup domain
control registers.


Will keep that in mind.

Regards,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: brcm80211: machine freezing hard with rfkill on

[Arend van Spriel]

On 07/19/13 09:02, Jiri Slaby wrote:

Hi,

our users report [1] that their machines freeze hard when they have
rfkill turned on and try to run wpa_supplicant or enable network
otherwise. This is with BCM43225 over PCI chip.

Any ideas what that could be or how to fix this?

[1] https://bugzilla.novell.com/show_bug.cgi?id=787649

thanks,


Hi Jiri,

Looking in the bug report it seems to be on 3.4 kernel. The commit below 
is done later.


Regards,
Arend
---
commit 82d8eba358badb466a4e988ecabf0668a8d92e9c
Author: Piotr Haber pha...@broadcom.com
Date:   Wed Sep 19 22:21:15 2012 +0200

brcmsmac: don't start device when RfKill is engaged

This patch fixes a bug when device is being started
while RfKill switch is engaged, leading to hang
due to partial initialization of hardware.

Tested-by: drag...@op.pl
Reviewed-by: Arend van Spriel ar...@broadcom.com
Reviewed-by: Hante Meuleman meule...@broadcom.com
Signed-off-by: Piotr Haber pha...@broadcom.com
Signed-off-by: Arend van Spriel ar...@broadcom.com
Signed-off-by: John W. Linville linvi...@tuxdriver.com


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 01:30 PM, Roger Quadros wrote:

On 07/18/2013 02:24 PM, Arend van Spriel wrote:

On 07/18/2013 01:18 PM, Roger Quadros wrote:

Hi Arend,

On 07/18/2013 11:41 AM, Arend van Spriel wrote:

Hi Tony,


We are using the panda board (es variant) for testing our SDIO based chips. For 
this we have an adapter card connection to expansion connector A. As this 
adapter is not publicly available we had internally patched board-omap4panda.c. 
Also we follow the -rc releases and use TFTP to boot the kernel image which 
requires USB.

Moving to 3.11-rc1 I found that the mentioned board file was removed by your 
commit:

commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren 
Date:   Thu May 30 12:53:05 2013 -0700

  ARM: OMAP2+: Remove board-omap4panda.c

As our patches on that file are internal I do not hold it against you. This is 
no regression and we need to fix it.

So my first step was to follow the recipe given in that commit. Beside that I 
noticed a thread about USB issue on LKML so I also applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros 
Date:   Tue Jun 18 19:04:47 2013 +0300

  ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is picked up by 
the kernel, but the USB does not seem very active. No ethernet connectivity. 
This does seem a regression to me. Is there some other patch that I need to get 
it going again?



I tried with your config and 3.11-rc1 kernel with the above commit on top and 
ethernet seems to
work for me. My boot log is attached.

Are you sure that you are building the DTB for panda-es and the bootloader is 
picking up the right file and
not an outdated one?


I appended the DTB to the kernel image thus avoiding the need to update u-boot 
(at least that is what I understood from Tony's commit).



I understand this can be a little tedious at first.

This is my u-boot boot.txt

fatload mmc 0:1 0x825f omap4-panda-es.dtb
fatload mmc 0:1 0x8030 uImage
set fdt_high 0x
setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 
rootwait
bootm 0x8030 - 0x825f

You need to generate boot.scr from the above boot.txt and place it in SD card 
boot partition.

mkimage -A arm -T script -C none -n "Boot Image" -d boot.txt boot.scr

And of course copy the omap4-panda-es.dtb to SD card boot partition.

hope this helps.


Thanks for sharing this.


Why is the version of SPL loader and u-boot different in your log?
You need to use the MLO file generated by the u-boot build along with the 
uImage.

Just to be sure we are on the same setup could you please try with latest 
u-boot release (2013-04). Thanks.


I recall having difficulty with TFTP boot using a 2013 u-boot release, but that 
hurdle is for later. I will try.



OK. We can figure this out as well.


I tried with same SPL and u-boot version, but that did not work out. So 
I moved to v2013.04 and the log looks better. I was especially 
interested in this:


[2.807434] usb 1-1.1: new high-speed USB device number 3 using 
ehci-omap
[2.932495] usb 1-1.1: New USB device found, idVendor=0424, 
idProduct=ec00
[2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, 
SerialNumbe0
[2.958770] smsc95xx v1.0.4 

Starting logging: OK 

Initializing random number generator... [3.045806] smsc95xx 
1-1.1:1.0 eth0


Regards,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 01:18 PM, Roger Quadros wrote:

Hi Arend,

On 07/18/2013 11:41 AM, Arend van Spriel wrote:

Hi Tony,


We are using the panda board (es variant) for testing our SDIO based chips. For 
this we have an adapter card connection to expansion connector A. As this 
adapter is not publicly available we had internally patched board-omap4panda.c. 
Also we follow the -rc releases and use TFTP to boot the kernel image which 
requires USB.

Moving to 3.11-rc1 I found that the mentioned board file was removed by your 
commit:

commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren 
Date:   Thu May 30 12:53:05 2013 -0700

 ARM: OMAP2+: Remove board-omap4panda.c

As our patches on that file are internal I do not hold it against you. This is 
no regression and we need to fix it.

So my first step was to follow the recipe given in that commit. Beside that I 
noticed a thread about USB issue on LKML so I also applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros 
Date:   Tue Jun 18 19:04:47 2013 +0300

 ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is picked up by 
the kernel, but the USB does not seem very active. No ethernet connectivity. 
This does seem a regression to me. Is there some other patch that I need to get 
it going again?



I tried with your config and 3.11-rc1 kernel with the above commit on top and 
ethernet seems to
work for me. My boot log is attached.

Are you sure that you are building the DTB for panda-es and the bootloader is 
picking up the right file and
not an outdated one?


I appended the DTB to the kernel image thus avoiding the need to update 
u-boot (at least that is what I understood from Tony's commit).



Why is the version of SPL loader and u-boot different in your log?
You need to use the MLO file generated by the u-boot build along with the 
uImage.

Just to be sure we are on the same setup could you please try with latest 
u-boot release (2013-04). Thanks.


I recall having difficulty with TFTP boot using a 2013 u-boot release, 
but that hurdle is for later. I will try.



cheers,
-roger


Thanks,
Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

* Arend van Spriel  [130718 01:47]:

So my first step was to follow the recipe given in that commit.
Beside that I noticed a thread about USB issue on LKML so I also
applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros 
Date:   Tue Jun 18 19:04:47 2013 +0300

 ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is
picked up by the kernel, but the USB does not seem very active. No
ethernet connectivity. This does seem a regression to me. Is there
some other patch that I need to get it going again?


There are few .dts related patches missing for USB. Roger can
point you to the current versions that Benoit should be queueing
for the -rc series.


Hope Roger or Benoit will chime in.


Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#

The wl12xx .dts changes for pandaboard are still missing too.

Then I'll be updating these soonish:
[PATCH 0/4] Updated omap_hsmmc SDIO and remuxing patches

Those are needed for the SDIO interrupt, SDIO will work also
without those.


Thanks for the pointers,

Arend


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 10:59 AM, Tony Lindgren wrote:

* Arend van Spriel ar...@broadcom.com [130718 01:47]:

So my first step was to follow the recipe given in that commit.
Beside that I noticed a thread about USB issue on LKML so I also
applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros rog...@ti.com
Date:   Tue Jun 18 19:04:47 2013 +0300

 ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is
picked up by the kernel, but the USB does not seem very active. No
ethernet connectivity. This does seem a regression to me. Is there
some other patch that I need to get it going again?


There are few .dts related patches missing for USB. Roger can
point you to the current versions that Benoit should be queueing
for the -rc series.


Hope Roger or Benoit will chime in.


Then for the SDIO with device tree, take a look at the following
patches:

[PATCH 0/3] WLAN support for omap4 when booted with devicetree
http://comments.gmane.org/gmane.linux.ports.arm.omap/97522#

The wl12xx .dts changes for pandaboard are still missing too.

Then I'll be updating these soonish:
[PATCH 0/4] Updated omap_hsmmc SDIO and remuxing patches

Those are needed for the SDIO interrupt, SDIO will work also
without those.


Thanks for the pointers,

Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 01:18 PM, Roger Quadros wrote:

Hi Arend,

On 07/18/2013 11:41 AM, Arend van Spriel wrote:

Hi Tony,


We are using the panda board (es variant) for testing our SDIO based chips. For 
this we have an adapter card connection to expansion connector A. As this 
adapter is not publicly available we had internally patched board-omap4panda.c. 
Also we follow the -rc releases and use TFTP to boot the kernel image which 
requires USB.

Moving to 3.11-rc1 I found that the mentioned board file was removed by your 
commit:

commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren t...@atomide.com
Date:   Thu May 30 12:53:05 2013 -0700

 ARM: OMAP2+: Remove board-omap4panda.c

As our patches on that file are internal I do not hold it against you. This is 
no regression and we need to fix it.

So my first step was to follow the recipe given in that commit. Beside that I 
noticed a thread about USB issue on LKML so I also applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros rog...@ti.com
Date:   Tue Jun 18 19:04:47 2013 +0300

 ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is picked up by 
the kernel, but the USB does not seem very active. No ethernet connectivity. 
This does seem a regression to me. Is there some other patch that I need to get 
it going again?



I tried with your config and 3.11-rc1 kernel with the above commit on top and 
ethernet seems to
work for me. My boot log is attached.

Are you sure that you are building the DTB for panda-es and the bootloader is 
picking up the right file and
not an outdated one?


I appended the DTB to the kernel image thus avoiding the need to update 
u-boot (at least that is what I understood from Tony's commit).



Why is the version of SPL loader and u-boot different in your log?
You need to use the MLO file generated by the u-boot build along with the 
uImage.

Just to be sure we are on the same setup could you please try with latest 
u-boot release (2013-04). Thanks.


I recall having difficulty with TFTP boot using a 2013 u-boot release, 
but that hurdle is for later. I will try.



cheers,
-roger


Thanks,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Regression 3.11-rc1: omap4panda: no usb and consequently no ethernet

[Arend van Spriel]

On 07/18/2013 01:30 PM, Roger Quadros wrote:

On 07/18/2013 02:24 PM, Arend van Spriel wrote:

On 07/18/2013 01:18 PM, Roger Quadros wrote:

Hi Arend,

On 07/18/2013 11:41 AM, Arend van Spriel wrote:

Hi Tony,


We are using the panda board (es variant) for testing our SDIO based chips. For 
this we have an adapter card connection to expansion connector A. As this 
adapter is not publicly available we had internally patched board-omap4panda.c. 
Also we follow the -rc releases and use TFTP to boot the kernel image which 
requires USB.

Moving to 3.11-rc1 I found that the mentioned board file was removed by your 
commit:

commit b42b918194c4791510ac049e3d507169a7de8544
Author: Tony Lindgren t...@atomide.com
Date:   Thu May 30 12:53:05 2013 -0700

  ARM: OMAP2+: Remove board-omap4panda.c

As our patches on that file are internal I do not hold it against you. This is 
no regression and we need to fix it.

So my first step was to follow the recipe given in that commit. Beside that I 
noticed a thread about USB issue on LKML so I also applied the following commit:

commit 352f573e59050c7a604c35c58b4bbfc51edebbee
Author: Roger Quadros rog...@ti.com
Date:   Tue Jun 18 19:04:47 2013 +0300

  ARM: OMAP2+: Provide alias to USB PHY clock

The attached kernel log seems to suggest that the device tree is picked up by 
the kernel, but the USB does not seem very active. No ethernet connectivity. 
This does seem a regression to me. Is there some other patch that I need to get 
it going again?



I tried with your config and 3.11-rc1 kernel with the above commit on top and 
ethernet seems to
work for me. My boot log is attached.

Are you sure that you are building the DTB for panda-es and the bootloader is 
picking up the right file and
not an outdated one?


I appended the DTB to the kernel image thus avoiding the need to update u-boot 
(at least that is what I understood from Tony's commit).



I understand this can be a little tedious at first.

This is my u-boot boot.txt

fatload mmc 0:1 0x825f omap4-panda-es.dtb
fatload mmc 0:1 0x8030 uImage
set fdt_high 0x
setenv bootargs console=ttyO2,115200n8 mem=1G@0x8000 root=/dev/mmcblk0p2 
rootwait
bootm 0x8030 - 0x825f

You need to generate boot.scr from the above boot.txt and place it in SD card 
boot partition.

mkimage -A arm -T script -C none -n Boot Image -d boot.txt boot.scr

And of course copy the omap4-panda-es.dtb to SD card boot partition.

hope this helps.


Thanks for sharing this.


Why is the version of SPL loader and u-boot different in your log?
You need to use the MLO file generated by the u-boot build along with the 
uImage.

Just to be sure we are on the same setup could you please try with latest 
u-boot release (2013-04). Thanks.


I recall having difficulty with TFTP boot using a 2013 u-boot release, but that 
hurdle is for later. I will try.



OK. We can figure this out as well.


I tried with same SPL and u-boot version, but that did not work out. So 
I moved to v2013.04 and the log looks better. I was especially 
interested in this:


[2.807434] usb 1-1.1: new high-speed USB device number 3 using 
ehci-omap
[2.932495] usb 1-1.1: New USB device found, idVendor=0424, 
idProduct=ec00
[2.932495] usb 1-1.1: New USB device strings: Mfr=0, Product=0, 
SerialNumbe0
[2.958770] smsc95xx v1.0.4 

Starting logging: OK 

Initializing random number generator... [3.045806] smsc95xx 
1-1.1:1.0 eth0


Regards,
Arend


--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Arend van Spriel]

On 07/16/2013 03:12 PM, Arend van Spriel wrote:

On 07/15/2013 04:05 PM, Roger Quadros wrote:

Hi Tony,

On 06/18/2013 07:04 PM, Roger Quadros wrote:

Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.

Without this, USB Host & Ethernet will not be functional with
device tree boots on Panda and uEVM.


Looks like this one got missed out.


Could it be because you promised to resend it (see [1]). I was upgrading
our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine,
but no USB/ethernet. Should I pickup all four patches?


Nevermind. The first three seem to be in already.


Regards,
Arend

[1] http://mid.gmane.org/51c2ec5f.8050...@ti.com


USB host no longer works on Panda with DT boot.
Could you please queue this for next 3.11-rc? Thanks.

cheers,
-roger






--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/4] ARM: OMAP2+: Provide alias to USB PHY clock

[Arend van Spriel]

On 07/15/2013 04:05 PM, Roger Quadros wrote:

Hi Tony,

On 06/18/2013 07:04 PM, Roger Quadros wrote:

Till the OMAP clocks are correctly defined in device tree, use
this temporary hack to provide clock alias to the USB PHY clocks.

Without this, USB Host & Ethernet will not be functional with
device tree boots on Panda and uEVM.


Looks like this one got missed out.


Could it be because you promised to resend it (see [1]). I was upgrading 
our test stuff to 3.11-rc1 and made a DT appended image. Boot went fine, 
but no USB/ethernet. Should I pickup all four patches?


Regards,
Arend

[1] http://mid.gmane.org/51c2ec5f.8050...@ti.com


USB host no longer works on Panda with DT boot.
Could you please queue this for next 3.11-rc? Thanks.

cheers,
-roger




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.10 regression: hang on suspend

[Arend van Spriel]

On 07/16/2013 09:34 AM, Ortwin Glück wrote:



On 16.07.2013 08:56, Stanislaw Gruszka wrote:

Apparently this commit changed suspend procedure on mac80211, but it's
not obvious for me why it hangs :-(


Hangs are hard :-) It just sits there with a black screen and a white
cursor in the top left corner...


What is your user space configuration (are you using NM or other
software or maybe just wpa_supplicant)? Are you using wowlan?
If you do add no_console_suspend boot parameter does it print some
diagnostic messages during suspend before the hang ?


Yes, I am using NM under KDE, with KDE triggered suspend. No wowlan
AFAIK. The last thing I see in the log is something from NetworkManager
that sees the device switching off. I can try again tonight and give you
the exact message.

I will also try without NM and bare wpa_supplicant and a plain suspend
through sysfs.

Any debug options you want me to enable? Netconsole won't work however...


Can you get more debug info if you try (as root/sudo -i):

echo devices > /sys/power/pm_test
echo mem > /sys/power state

Regards,
Arend


Ortwin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG] 3.10 regression: hang on suspend

[Arend van Spriel]

On 07/16/2013 09:34 AM, Ortwin Glück wrote:



On 16.07.2013 08:56, Stanislaw Gruszka wrote:

Apparently this commit changed suspend procedure on mac80211, but it's
not obvious for me why it hangs :-(


Hangs are hard :-) It just sits there with a black screen and a white
cursor in the top left corner...


What is your user space configuration (are you using NM or other
software or maybe just wpa_supplicant)? Are you using wowlan?
If you do add no_console_suspend boot parameter does it print some
diagnostic messages during suspend before the hang ?


Yes, I am using NM under KDE, with KDE triggered suspend. No wowlan
AFAIK. The last thing I see in the log is something from NetworkManager
that sees the device switching off. I can try again tonight and give you
the exact message.

I will also try without NM and bare wpa_supplicant and a plain suspend
through sysfs.

Any debug options you want me to enable? Netconsole won't work however...


Can you get more debug info if you try (as root/sudo -i):

echo devices  /sys/power/pm_test
echo mem  /sys/power state

Regards,
Arend


Ortwin
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/




--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/