On 02/15/2016 09:00 AM, Uwe Kleine-König wrote:
On Mon, Feb 15, 2016 at 07:41:19AM -0800, Guenter Roeck wrote:
On 02/15/2016 02:59 AM, Uwe Kleine-König wrote:
Hello Guenter,
On Sun, Feb 14, 2016 at 08:50:10AM -0800, Guenter Roeck wrote:
Uwe,
Your patch 'driver-core: platform: probe of-devices only using list of
compatibles' causes the following qemu tests to crash in -next.
arm:vexpress-a9:vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
Crash log:
VFS: Cannot open root device "mmcblk0" or unknown-block(0,0): error -6
Please append a correct "root=" boot option; here are the available partitions:
1f00 131072 mtdblock0 (driver?)
1f01 32768 mtdblock1 (driver?)
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Can you provide a complete boot log? This might already reveal which
device is failing. It might not be the mmci device but something it
depends on (clock, bus parent, irq).
Sure, something else may be failing, but why does reverting your patch
fix the problem ?
Well, my patch made matching of platform devices to platform drivers
more strict. Your machine relies on the respective binding though. So of
course reverting my patch "repairs" your machine, but that doesn't
necessarily mean that my patch is wrong. Even though I'm convinced in
the meantime by Russell that there are false positives it doesn't
necessarily imply that your case is such a false positive, too.
One example of a combination of driver + device I intended to break with
my patch was drivers/mtd/nand/mxc_nand.c and devices that got bound to
that by name. The driver does:
const struct of_device_id *of_id =
of_match_device(mxcnd_dt_ids, host->dev);
and doesn't handle of_id being NULL after that. Some people argued (also
for other drivers in similar situations) that this cannot happen because
all compatibles had a non-NULL device_id. That is an error that is easy
to make and so the idea was to just not bind in such a case and safe the
user from the surprise.
I added some debugging on top of your patch, and get:
platform basic-mmio-gpio.1.auto: Device node exists [/smb/motherboard/iofpga@7,00000000/sysreg@00000/sys_led@08], of_driver_match_device() failed
platform basic-mmio-gpio.1.auto: platform_match_id() succeeded
platform basic-mmio-gpio.2.auto: Device node exists [/smb/motherboard/iofpga@7,00000000/sysreg@00000/sys_mci@48], of_driver_match_device() failed
platform basic-mmio-gpio.2.auto: platform_match_id() succeeded
platform basic-mmio-gpio.3.auto: Device node exists [/smb/motherboard/iofpga@7,00000000/sysreg@00000/sys_flash@4c], of_driver_match_device() failed
platform basic-mmio-gpio.3.auto: platform_match_id() succeeded
So it isn't the mmc driver failing to instantiate directly,
but (I think) vexpress-sysreg.
Guenter
--
To unsubscribe from this list: send the line "unsubscribe linux-next" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
