Hi all.

This patch intends to fix an unresolved symbol 'init_cmd640_vlb' error
when compiling kernel 2.4.22 using

     CONFIG_IDE=m
     CONFIG_BLK_DEV_IDE=m

and an enabled 'CONFIG_BLK_DEV_CMD640' option. The problem would show up
on the first attempt to run 'depmod' or otherwise deal with IDE modules.

I've not seen any fix for this in any recent prerelease.

The problem is caused by the way 'cmd640' is included in the kernel. If

     CONFIG_BLK_DEV_CMD640=y

(which is the only answer offered besides 'n' for a stock 2.4.22), the
'cmd640' code will be put into the kernel statically. As 'ide-core.o'
will be a module and it will contain a reference to the (unexported)
function 'init_cmd640_vlb' of 'cmd640.c', symbol resolution will fail.

The following patch assumes that 'cmd640' is meant to be an independent
module now (as all other IDE drivers in 'drivers/ide/pci') if IDE core is
modular. The patch only adds the required configuration option changes to
allow an additional answer 'm' for 'CONFIG_BLK_DEV_CMD640' (and disabling
'y' completely if IDE is modular). Boolean 'CONFIG_BLK_DEV_CMD640_ENHANCED'
may now be set to 'y' if 'CONFIG_BLK_DEV_CMD640' is either 'y' or 'm'.

With 'CONFIG_BLK_DEV_CMD640=m', the reference to 'init_cmd640_vlb' from
'ide.c' will be omitted, leaving VLB handling to the respective module
parameter of 'cmd640.o'.

NB: While I have verified that symbols resolve cleanly and 'cmd640.o' loads
     without problems, I currently have no hardware to actually test any
     CMD640 chipsets on (I only added the driver to my configuration for
     completeness), so I cannot tell whether the modular driver actually
     works as it should. At least it doesn't break IDE module loading now.

Best regards,
Alex

[ Please send answers to my From address.
   I'm not subscribed to the kernel mailing list. ]