[opensuse-arm] Re: [opensuse-kernel] [PATCH] ARM: update armv7 default config - master branch - openSUSE ARM

newer
[opensuse-arm] [PATCH] Disable...

[opensuse-arm] Re: [opensuse-kernel] [PATCH] ARM: update armv7 default config - master branch

older
[opensuse-arm] kernel-default...

Guillaume Gardet

3 Apr 2014 3 Apr '14

12:32

CC'ing -arm ML Le 03/04/2014 13:48, Alexander Graf a écrit :

...

On 03.04.14 13:47, Guillaume Gardet wrote:

...
Le 03/04/2014 13:39, Alexander Graf a écrit :

...
On 02.04.14 20:48, Guillaume Gardet wrote:

...
Hi,

please find in attachment an ARMv7 -default config update to fix Ethernet and HDMI output on iMX6 SABRE Lite board. It also add initial support to USB on this board.

This patch is against master branch.

Signed-off-by: Guillaume GARDET Moving modules from =m to =y is the wrong answer usually. Why don't the modules work as modules? I do not know. Modules are loaded with no error but they do not work. The fact is switching FEC and SDMA from =m to =y fix the problems. It is true for 13.1 and master branches.

Yes, I've spent some time myself to fix FEC as a module on i.MX53 a while ago. We really don't want to even start going into the game of enabling random devices as =y on the default config, otherwise we'll end up with a 30MB kernel on all boards.

I agree, but the fact is we have no board which works really fine ATM. See: http://en.opensuse.org/openSUSE:Supported_ARM_boards#13.1 There are only RPi and Chromebook which have a correct support (and they use _downstream_ kernels). But chromebook boot only once and need a hack to boot then (I am on it, Marcus gave me some hints to fix that using kiwi hooks) and had a lot of X stability problems (random freezes, X crash when switching VT). Raspberry Pi is not booting at all as is (kiwi partitioning bug) and need a hack to get a bootable image: http://en.opensuse.org/HCL:Raspberry_Pi#Known_Issues Maybe Beaglebone or Beaglebone black have a good support? (I do not have such devices and there is no feedback on our wiki) Now, SABRE Lite is the only board where I got graphics working with upstream kernel. The last blocking problem on this board is USB which is not working, even with imx_v6_v7_defconfig. The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible. I think we should use again our Trello board or setup a wiki page or something to write down what must be done for each board and who is taking care of each task. What do you think about that? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Show replies by date

Alexander Graf

3 Apr 3 Apr

12:51

On 03.04.14 14:32, Guillaume Gardet wrote:

...

CC'ing -arm ML

Le 03/04/2014 13:48, Alexander Graf a écrit :

...
On 03.04.14 13:47, Guillaume Gardet wrote:

...
Le 03/04/2014 13:39, Alexander Graf a écrit :

...
On 02.04.14 20:48, Guillaume Gardet wrote:

...
Hi,

please find in attachment an ARMv7 -default config update to fix Ethernet and HDMI output on iMX6 SABRE Lite board. It also add initial support to USB on this board.

This patch is against master branch.

Signed-off-by: Guillaume GARDET Moving modules from =m to =y is the wrong answer usually. Why don't the modules work as modules? I do not know. Modules are loaded with no error but they do not work. The fact is switching FEC and SDMA from =m to =y fix the problems. It is true for 13.1 and master branches. Yes, I've spent some time myself to fix FEC as a module on i.MX53 a while ago. We really don't want to even start going into the game of enabling random devices as =y on the default config, otherwise we'll end up with a 30MB kernel on all boards. I agree, but the fact is we have no board which works really fine ATM. See: http://en.opensuse.org/openSUSE:Supported_ARM_boards#13.1 There are only RPi and Chromebook which have a correct support (and they use _downstream_ kernels). But chromebook boot only once and need a hack to boot then (I am on it, Marcus gave me some hints to fix that using kiwi hooks) and had a lot of X stability problems (random freezes, X crash when switching VT). Raspberry Pi is not booting at all as is (kiwi partitioning bug) and need a hack to get a bootable image: http://en.opensuse.org/HCL:Raspberry_Pi#Known_Issues Maybe Beaglebone or Beaglebone black have a good support? (I do not have such devices and there is no feedback on our wiki)

Now, SABRE Lite is the only board where I got graphics working with upstream kernel. The last blocking problem on this board is USB which is not working, even with imx_v6_v7_defconfig.

I guess we can ask Sascha here too :).

...

The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible.

I agree with 1), but it'll be a real nightmare to clean things up once we start going down the path of 2). Let's see if Sascha has ideas to get us out of the mess where we need =y for things that really shouldn't have to be compiled in.

...

I think we should use again our Trello board or setup a wiki page or something to write down what must be done for each board and who is taking care of each task.

What do you think about that?

I think that makes sense. I would also consider "Contrib" a good place to play with hacks like setting options to =y to at least get _something_ working. So if you like we can create a contrib directory for i.MX6 and put a kernel in there that has everything it needs compiled in. Alex -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

13:36

Removed -kernel ML and sacha here since it is only for openSUSE ARM community. Le 03/04/2014 14:51, Alexander Graf a écrit :

...

On 03.04.14 14:32, Guillaume Gardet wrote:

...
CC'ing -arm ML

Le 03/04/2014 13:48, Alexander Graf a écrit :

...
On 03.04.14 13:47, Guillaume Gardet wrote:

...
Le 03/04/2014 13:39, Alexander Graf a écrit :

...
On 02.04.14 20:48, Guillaume Gardet wrote:

...
Hi,

please find in attachment an ARMv7 -default config update to fix Ethernet and HDMI output on iMX6 SABRE Lite board. It also add initial support to USB on this board.

This patch is against master branch.

Signed-off-by: Guillaume GARDET Moving modules from =m to =y is the wrong answer usually. Why don't the modules work as modules? I do not know. Modules are loaded with no error but they do not work. The fact is switching FEC and SDMA from =m to =y fix the problems. It is true for 13.1 and master branches. Yes, I've spent some time myself to fix FEC as a module on i.MX53 a while ago. We really don't want to even start going into the game of enabling random devices as =y on the default config, otherwise we'll end up with a 30MB kernel on all boards. I agree, but the fact is we have no board which works really fine ATM. See: http://en.opensuse.org/openSUSE:Supported_ARM_boards#13.1 There are only RPi and Chromebook which have a correct support (and they use _downstream_ kernels). But chromebook boot only once and need a hack to boot then (I am on it, Marcus gave me some hints to fix that using kiwi hooks) and had a lot of X stability problems (random freezes, X crash when switching VT). Raspberry Pi is not booting at all as is (kiwi partitioning bug) and need a hack to get a bootable image: http://en.opensuse.org/HCL:Raspberry_Pi#Known_Issues Maybe Beaglebone or Beaglebone black have a good support? (I do not have such devices and there is no feedback on our wiki)

Now, SABRE Lite is the only board where I got graphics working with upstream kernel. The last blocking problem on this board is USB which is not working, even with imx_v6_v7_defconfig.

I guess we can ask Sascha here too :).

...
The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible.

I agree with 1), but it'll be a real nightmare to clean things up once we start going down the path of 2). Let's see if Sascha has ideas to get us out of the mess where we need =y for things that really shouldn't have to be compiled in.

It won't be a nightmare if things are tracked (bugzilla, trello, wiki page or something). The best thing to do, would be try to fix things more or less quickly and if we do not manage to fix it, do 2) then 3). (Maybe in a Contrib repo as you wrote below).

...

...
I think we should use again our Trello board or setup a wiki page or something to write down what must be done for each board and who is taking care of each task.

What do you think about that?

I think that makes sense. I would also consider "Contrib" a good place to play with hacks like setting options to =y to at least get _something_ working. So if you like we can create a contrib directory for i.MX6 and put a kernel in there that has everything it needs compiled in.

It may be a good idea, but before to proceed for iMX6, let's see if sacha could help us. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Sascha Hauer

13:44

On Thu, Apr 03, 2014 at 02:51:16PM +0200, Alexander Graf wrote:

...

I guess we can ask Sascha here too :).

...
The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible.

I agree with 1), but it'll be a real nightmare to clean things up once we start going down the path of 2). Let's see if Sascha has ideas to get us out of the mess where we need =y for things that really shouldn't have to be compiled in.

I just tried vanilla v3.14 with the imx_v6_v7_defconfig. The OTG port on the sabrelite works for me. The other hoast ports bail out with: hub 2-0:1.0: cannot reset port 1 (err = -32) hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad? I also tried building USB as modules, same result. Oh damn, sound fails badly when SDMA is compiled as a module: pc : [<801406a8>] lr : [<8031eca4>] psr: a0000113 sp : bf05fce0 ip : bf05fcf0 fp : bf05fcec r10: bf025f80 r9 : be89ffc0 r8 : bf13ac00 r7 : bf13ac10 r6 : fffffdfb r5 : bf7e3544 r4 : be89fe10 r3 : bf05e000 r2 : 00000000 r1 : 00000000 r0 : bf13ac18 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000017 Process swapper/0 (pid: 1, stack limit = 0xbf05e240) Stack: (0xbf05fce0 to 0xbf060000) fce0: bf05fcfc bf05fcf0 8031eca4 801406a8 bf05fdcc bf05fd00 8047fc8c 8031ec90 fd00: 00000000 be89ffc0 be89fe10 bf1249f8 bf05fd34 be89fe20 8014314c 02028000 fd20: 0202bfff bf7e3580 00000200 00000000 00000000 00000000 00000000 be8dcc08 fd40: 00000000 bf1249f8 00000000 80882014 bf05e000 00000001 bf05fd8c bf05fd68 fd60: 00000004 00000025 00000001 00000000 00000000 be8dcc08 bf05e000 00000001 fd80: bf05fdb4 bf05fd90 80141304 8014292c bf13ac10 bf13ac18 00000000 00000000 fda0: 80882014 bf13ac10 80882014 00000000 00000000 80882014 bf05e000 80820f48 fdc0: bf05fde4 bf05fdd0 80323af4 8047fa40 80dd0060 bf13ac10 bf05fe0c bf05fde8 fde0: 80322514 80323ae0 00000000 bf13ac10 80882014 bf13ac44 00000000 80814498 fe00: bf05fe2c bf05fe10 803226cc 80322408 bf11dcdc 00000000 80882014 80322630 fe20: bf05fe54 bf05fe30 80320ae4 8032263c bf0048a8 bf11dcd0 be8dd258 80882014 fe40: be8dd280 80861a80 bf05fe64 bf05fe58 8032200c 80320a94 bf05fe8c bf05fe68 fe60: 80321c08 80321ff8 8079d340 bf05fe78 80882014 00000006 8088c480 807e355c fe80: bf05fea4 bf05fe90 80322d84 80321b38 8082d478 00000006 bf05feb4 bf05fea8 fea0: 80323a14 80322d10 bf05fec4 bf05feb8 808144b0 803239d0 bf05ff54 bf05fec8 fec0: 80008a68 808144a4 805ecd00 800656cc 00000000 00000000 bf05ff1c bf05fee8 fee0: bf05ff0c bf05fef0 807e3500 80295590 807e355c bfffcc52 80605308 000000ae ff00: bf05ff54 bf05ff10 800430dc 807e3568 bf05ff34 00000006 00000006 807e0af0 ff20: 00000000 80789348 bf05ff54 8082d478 00000006 8088c480 807e355c 000000ae ff40: 80820f3c 80820f48 bf05ff94 bf05ff58 807e3cc0 80008980 00000006 00000006 ff60: 807e355c ffffffff bf05e000 00000000 805e1340 00000000 00000000 00000000 ff80: 00000000 00000000 bf05ffac bf05ff98 805e1350 807e3bc8 ffffffff 00000000 ffa0: 00000000 bf05ffb0 8000ebe8 805e134c 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff Backtrace: [<8014069c>] (sysfs_remove_file_ns) from [<8031eca4>] (device_remove_file+0x20/0x24) [<8031ec84>] (device_remove_file) from [<8047fc8c>] (fsl_ssi_probe+0x258/0x748) [<8047fa34>] (fsl_ssi_probe) from [<80323af4>] (platform_drv_probe+0x20/0x50) ... I haven't looked into this, but this should be fixable quite easily. I'll have look. Sascha -- Pengutronix e.K. | | Industrial Linux Solutions | http://www.pengutronix.de/ | Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 | Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 | -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

15:49

Le 03/04/2014 15:44, Sascha Hauer a écrit :

...

...
I guess we can ask Sascha here too :).

...
The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible. I agree with 1), but it'll be a real nightmare to clean things up once we start going down the path of 2). Let's see if Sascha has ideas to get us out of the mess where we need =y for things that really shouldn't have to be compiled in. I just tried vanilla v3.14 with the imx_v6_v7_defconfig. The OTG port on

On Thu, Apr 03, 2014 at 02:51:16PM +0200, Alexander Graf wrote: the sabrelite works for me. The other hoast ports bail out with:

It does not here with imx_v6_v7_defconfig and openSUSE 3.14 kernel. After lots of tests, I finally found something. Our drivers/usb/chipidea/{Makefile,Kconfig} are not the same as in vanilla kernel. :( See: http://kernel.opensuse.org/cgit/kernel/tree/drivers/usb/chipidea And: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers... It seems to be because of http://kernel.opensuse.org/cgit/kernel/commit/drivers/usb/chipidea/Makefile?... I noticed that CONFIG_USB_CHIPIDEA CONFIG_USB_CHIPIDEA_UDC CONFIG_USB_CHIPIDEA_HOST were selectable but CONFIG_USB_CHIPIDEA_IMX (special openSUSE option :( ) was unselectable because it 'depends on OF_DEVICE' which does not exist anymore. I replaced it by 'depends on OF', select it and rebuilt the kernel. And it works with imx_v6_v7_defconfig! :) If I built all USB modules as module (=m) instead of built-in, it does not work at all like previously. If I built all USB modules as built-in except CONFIG_USB_EHCI_MXC, I get your USB cable error messages below. Alex, should I send a patch to replace 'depends on OF_DEVICE' with 'depends on OF' for CONFIG_USB_CHIPIDEA_IMX? Why this patch did not get upstream: http://kernel.opensuse.org/cgit/kernel/commit/drivers/usb/chipidea/Makefile?... ? It would save a lot of time...

...

hub 2-0:1.0: cannot reset port 1 (err = -32) hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?

I also tried building USB as modules, same result.

Oh damn, sound fails badly when SDMA is compiled as a module:

pc : [<801406a8>] lr : [<8031eca4>] psr: a0000113 sp : bf05fce0 ip : bf05fcf0 fp : bf05fcec r10: bf025f80 r9 : be89ffc0 r8 : bf13ac00 r7 : bf13ac10 r6 : fffffdfb r5 : bf7e3544 r4 : be89fe10 r3 : bf05e000 r2 : 00000000 r1 : 00000000 r0 : bf13ac18 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000017 Process swapper/0 (pid: 1, stack limit = 0xbf05e240) Stack: (0xbf05fce0 to 0xbf060000) fce0: bf05fcfc bf05fcf0 8031eca4 801406a8 bf05fdcc bf05fd00 8047fc8c 8031ec90 fd00: 00000000 be89ffc0 be89fe10 bf1249f8 bf05fd34 be89fe20 8014314c 02028000 fd20: 0202bfff bf7e3580 00000200 00000000 00000000 00000000 00000000 be8dcc08 fd40: 00000000 bf1249f8 00000000 80882014 bf05e000 00000001 bf05fd8c bf05fd68 fd60: 00000004 00000025 00000001 00000000 00000000 be8dcc08 bf05e000 00000001 fd80: bf05fdb4 bf05fd90 80141304 8014292c bf13ac10 bf13ac18 00000000 00000000 fda0: 80882014 bf13ac10 80882014 00000000 00000000 80882014 bf05e000 80820f48 fdc0: bf05fde4 bf05fdd0 80323af4 8047fa40 80dd0060 bf13ac10 bf05fe0c bf05fde8 fde0: 80322514 80323ae0 00000000 bf13ac10 80882014 bf13ac44 00000000 80814498 fe00: bf05fe2c bf05fe10 803226cc 80322408 bf11dcdc 00000000 80882014 80322630 fe20: bf05fe54 bf05fe30 80320ae4 8032263c bf0048a8 bf11dcd0 be8dd258 80882014 fe40: be8dd280 80861a80 bf05fe64 bf05fe58 8032200c 80320a94 bf05fe8c bf05fe68 fe60: 80321c08 80321ff8 8079d340 bf05fe78 80882014 00000006 8088c480 807e355c fe80: bf05fea4 bf05fe90 80322d84 80321b38 8082d478 00000006 bf05feb4 bf05fea8 fea0: 80323a14 80322d10 bf05fec4 bf05feb8 808144b0 803239d0 bf05ff54 bf05fec8 fec0: 80008a68 808144a4 805ecd00 800656cc 00000000 00000000 bf05ff1c bf05fee8 fee0: bf05ff0c bf05fef0 807e3500 80295590 807e355c bfffcc52 80605308 000000ae ff00: bf05ff54 bf05ff10 800430dc 807e3568 bf05ff34 00000006 00000006 807e0af0 ff20: 00000000 80789348 bf05ff54 8082d478 00000006 8088c480 807e355c 000000ae ff40: 80820f3c 80820f48 bf05ff94 bf05ff58 807e3cc0 80008980 00000006 00000006 ff60: 807e355c ffffffff bf05e000 00000000 805e1340 00000000 00000000 00000000 ff80: 00000000 00000000 bf05ffac bf05ff98 805e1350 807e3bc8 ffffffff 00000000 ffa0: 00000000 bf05ffb0 8000ebe8 805e134c 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff Backtrace: [<8014069c>] (sysfs_remove_file_ns) from [<8031eca4>] (device_remove_file+0x20/0x24) [<8031ec84>] (device_remove_file) from [<8047fc8c>] (fsl_ssi_probe+0x258/0x748) [<8047fa34>] (fsl_ssi_probe) from [<80323af4>] (platform_drv_probe+0x20/0x50) ...

I haven't looked into this, but this should be fixable quite easily. I'll have look.

Ok. Thanks. Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

Guillaume Gardet

11 Jun 11 Jun

10:40

New subject: [opensuse-arm] iMX6 USB support with SDMA as a module (was: Re: [opensuse-kernel] [PATCH] ARM: update armv7 default config - master branch)

Hi Sascha, Le 03/04/2014 15:44, Sascha Hauer a écrit :

...

...
I guess we can ask Sascha here too :).

...
The main things to do for boards support are : 1) Get boards booting Linux (should be a minimum). 2) Have a maximum number of supported devices (USB, sound, video, etc.) on each board (even if it does mean to have '=y' instead of '=m'). 3) Clean-up / fix our kernel / kernel configs to use modules (=m) instead of built-in (=y) when it is possible. I agree with 1), but it'll be a real nightmare to clean things up once we start going down the path of 2). Let's see if Sascha has ideas to get us out of the mess where we need =y for things that really shouldn't have to be compiled in. I just tried vanilla v3.14 with the imx_v6_v7_defconfig. The OTG port on

On Thu, Apr 03, 2014 at 02:51:16PM +0200, Alexander Graf wrote: the sabrelite works for me. The other hoast ports bail out with:

hub 2-0:1.0: cannot reset port 1 (err = -32) hub 2-0:1.0: Cannot enable port 1. Maybe the USB cable is bad?

I also tried building USB as modules, same result.

Oh damn, sound fails badly when SDMA is compiled as a module:

pc : [<801406a8>] lr : [<8031eca4>] psr: a0000113 sp : bf05fce0 ip : bf05fcf0 fp : bf05fcec r10: bf025f80 r9 : be89ffc0 r8 : bf13ac00 r7 : bf13ac10 r6 : fffffdfb r5 : bf7e3544 r4 : be89fe10 r3 : bf05e000 r2 : 00000000 r1 : 00000000 r0 : bf13ac18 Flags: NzCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment kernel Control: 10c53c7d Table: 1000404a DAC: 00000017 Process swapper/0 (pid: 1, stack limit = 0xbf05e240) Stack: (0xbf05fce0 to 0xbf060000) fce0: bf05fcfc bf05fcf0 8031eca4 801406a8 bf05fdcc bf05fd00 8047fc8c 8031ec90 fd00: 00000000 be89ffc0 be89fe10 bf1249f8 bf05fd34 be89fe20 8014314c 02028000 fd20: 0202bfff bf7e3580 00000200 00000000 00000000 00000000 00000000 be8dcc08 fd40: 00000000 bf1249f8 00000000 80882014 bf05e000 00000001 bf05fd8c bf05fd68 fd60: 00000004 00000025 00000001 00000000 00000000 be8dcc08 bf05e000 00000001 fd80: bf05fdb4 bf05fd90 80141304 8014292c bf13ac10 bf13ac18 00000000 00000000 fda0: 80882014 bf13ac10 80882014 00000000 00000000 80882014 bf05e000 80820f48 fdc0: bf05fde4 bf05fdd0 80323af4 8047fa40 80dd0060 bf13ac10 bf05fe0c bf05fde8 fde0: 80322514 80323ae0 00000000 bf13ac10 80882014 bf13ac44 00000000 80814498 fe00: bf05fe2c bf05fe10 803226cc 80322408 bf11dcdc 00000000 80882014 80322630 fe20: bf05fe54 bf05fe30 80320ae4 8032263c bf0048a8 bf11dcd0 be8dd258 80882014 fe40: be8dd280 80861a80 bf05fe64 bf05fe58 8032200c 80320a94 bf05fe8c bf05fe68 fe60: 80321c08 80321ff8 8079d340 bf05fe78 80882014 00000006 8088c480 807e355c fe80: bf05fea4 bf05fe90 80322d84 80321b38 8082d478 00000006 bf05feb4 bf05fea8 fea0: 80323a14 80322d10 bf05fec4 bf05feb8 808144b0 803239d0 bf05ff54 bf05fec8 fec0: 80008a68 808144a4 805ecd00 800656cc 00000000 00000000 bf05ff1c bf05fee8 fee0: bf05ff0c bf05fef0 807e3500 80295590 807e355c bfffcc52 80605308 000000ae ff00: bf05ff54 bf05ff10 800430dc 807e3568 bf05ff34 00000006 00000006 807e0af0 ff20: 00000000 80789348 bf05ff54 8082d478 00000006 8088c480 807e355c 000000ae ff40: 80820f3c 80820f48 bf05ff94 bf05ff58 807e3cc0 80008980 00000006 00000006 ff60: 807e355c ffffffff bf05e000 00000000 805e1340 00000000 00000000 00000000 ff80: 00000000 00000000 bf05ffac bf05ff98 805e1350 807e3bc8 ffffffff 00000000 ffa0: 00000000 bf05ffb0 8000ebe8 805e134c 00000000 00000000 00000000 00000000 ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000 ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 ffffffff ffffffff Backtrace: [<8014069c>] (sysfs_remove_file_ns) from [<8031eca4>] (device_remove_file+0x20/0x24) [<8031ec84>] (device_remove_file) from [<8047fc8c>] (fsl_ssi_probe+0x258/0x748) [<8047fa34>] (fsl_ssi_probe) from [<80323af4>] (platform_drv_probe+0x20/0x50) ...

I haven't looked into this, but this should be fixable quite easily. I'll have look.

Any progress on that one? Guillaume -- To unsubscribe, e-mail: opensuse-arm+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-arm+owner@opensuse.org

3613

Age (days ago)

3682

Last active (days ago)

List overview

Download

5 comments

3 participants

participants (3)

Alexander Graf
Guillaume Gardet
Sascha Hauer