All of lore.kernel.org
 help / color / mirror / Atom feed
From: Florian Fainelli <f.fainelli@gmail.com>
To: Guenter Roeck <linux@roeck-us.net>,
	"linux-next@vger.kernel.org" <linux-next@vger.kernel.org>
Cc: "Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Network Development" <netdev@vger.kernel.org>,
	"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
	"David S. Miller" <davem@davemloft.net>
Subject: Re: Crashes in -next due to 'phy: add support for a reset-gpio specification'
Date: Tue, 17 May 2016 22:01:37 -0700	[thread overview]
Message-ID: <573BF731.4090002@gmail.com> (raw)
In-Reply-To: <573BF177.6090507@roeck-us.net>

Le 17/05/2016 21:37, Guenter Roeck a écrit :
> Hi,
> 
> my xtensa qemu tests crash in -next as follows.
> 
> [ ... ]
> 
> [    9.366256] libphy: ethoc-mdio: probed
> [    9.367389]  (null): could not attach to PHY
> [    9.368555]  (null): failed to probe MDIO bus
> [    9.371540] Unable to handle kernel paging request at virtual address
> 0000001c
> [    9.371540]  pc = d0320926, ra = 903209d1
> [    9.375358] Oops: sig: 11 [#1]
> [    9.376081] PREEMPT
> [    9.377080] CPU: 0 PID: 1 Comm: swapper Not tainted
> 4.6.0-next-20160517 #1
> [    9.378397] task: d7c2c000 ti: d7c30000 task.ti: d7c30000
> [    9.379394] a00: 903209d1 d7c31bd0 d7fb5810 00000001 00000000
> 00000000 d7f45c00 d7c31bd0
> [    9.382298] a08: 00000000 00000000 00000000 00000000 00060100
> d04b0c10 d7f45dfc d7c31bb0
> [    9.385732] pc: d0320926, ps: 00060110, depc: 00000018, excvaddr:
> 0000001c
> [    9.387061] lbeg: d0322e35, lend: d0322e57 lcount: 00000000, sar:
> 00000011
> [    9.388173]
> Stack: d7c31be0 00060700 d7f45c00 d7c31bd0 9021d509 d7c31c30 d7f45c00
> 00000000
>        d0485dcc d0485dcc d7fb5810 d7c2c000 00000000 d7c31c30 d7f45c00
> d025befc
>        d0485dcc d7c30000 d7f45c34 d7c31bf0 9021c985 d7c31c50 d7f45c00
> d7f45c34
> [    9.396652] Call Trace:
> [    9.397469]  [<d021d4d9>] __device_release_driver+0x7d/0x98
> [    9.398869]  [<d021d509>] device_release_driver+0x15/0x20
> [    9.400247]  [<d021c985>] bus_remove_device+0xc1/0xd4
> [    9.401569]  [<d021a935>] device_del+0x109/0x15c
> [    9.402794]  [<d025c3f9>] phy_mdio_device_remove+0xd/0x18
> [    9.404124]  [<d025d264>] mdiobus_unregister+0x40/0x5c
> [    9.405444]  [<d025ff44>] ethoc_probe+0x534/0x5b8
> [    9.406742]  [<d021e2e0>] platform_drv_probe+0x28/0x48
> [    9.408122]  [<d021d1e5>] driver_probe_device+0x101/0x234
> [    9.409499]  [<d021d395>] __driver_attach+0x7d/0x98
> [    9.410809]  [<d021bd80>] bus_for_each_dev+0x30/0x5c
> [    9.412104]  [<d021cdf0>] driver_attach+0x14/0x18
> [    9.413385]  [<d021ca61>] bus_add_driver+0xc9/0x198
> [    9.414686]  [<d021d7d4>] driver_register+0x70/0xa0
> [    9.416001]  [<d021e2b4>] __platform_driver_register+0x24/0x28
> [    9.417463]  [<d04a1d34>] ethoc_driver_init+0x10/0x14
> [    9.418824]  [<d00032c8>] do_one_initcall+0x80/0x1ac
> [    9.420083]  [<d049386d>] kernel_init_freeable+0x131/0x198
> [    9.421504]  [<d03236e8>] kernel_init+0xc/0xb0
> [    9.422693]  [<d000482c>] ret_from_kernel_thread+0x8/0xc
> 
> Bisect points to commit da47b4572056 ("phy: add support for a reset-gpio
> specification").
> Bisect log is attached. Reverting the patch fixes the problem.

Aside from what you pointed out, this patch was still in dicussion when
it got merged, since we got a concurrent patch from Sergei which tries
to deal with the same kind of problem.

Do you mind sending a revert, or I can do that first thing in the morning.

> 
> I think there may be a number of problems, all of them exposed by the patch
> but really separate.
> 
> GPIOLIB is not configured in my test case, meaning gpiod_get_optional()
> returns -ENOSYS, and phy_probe() thus returns an error. Question here is if
> it is really appropriate for the XXX_optional() gpiolib functions to return
> an error if GPIOLIB is not configured. Either case, result is that pretty
> much all phy registrations will now fail if GPIOLIB is not configured.
> 
> Also, I suspect that there may be a bug in the error handling path
> of ethoc_probe(). No idea what exactly is wrong, though. Other drivers
> use pretty much the same code sequence for mdio registration and associated
> error handling.
> 
> Last but not least, something seems to be wrong with the use of dev_err()
> with &netdev->dev if register_netdev() has not yet been called. Maybe
> someone
> has some insight ?

It all depends if SET_NETDEV_DEV() has had a chance to run, but in
general it is kind of a bad idea to use netdev_* before the interface
has been registered, since it won't have any valid name.
-- 
Florian

  reply	other threads:[~2016-05-18  5:01 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-18  4:37 Crashes in -next due to 'phy: add support for a reset-gpio specification' Guenter Roeck
2016-05-18  5:01 ` Florian Fainelli [this message]
2016-05-18  6:52   ` Guenter Roeck
2016-05-18 15:45   ` Guenter Roeck
2016-05-22 10:10 ` Uwe Kleine-König
2016-05-22 15:41   ` Guenter Roeck
2016-05-22 18:21     ` Uwe Kleine-König
2016-05-23  1:06       ` Guenter Roeck
2016-05-23  5:25         ` Uwe Kleine-König

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=573BF731.4090002@gmail.com \
    --to=f.fainelli@gmail.com \
    --cc=davem@davemloft.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-next@vger.kernel.org \
    --cc=linux@roeck-us.net \
    --cc=netdev@vger.kernel.org \
    --cc=u.kleine-koenig@pengutronix.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.