Re: BUG: unable to handle kernel paging request in usb_match_id()

[Greg Kroah-Hartman]

On Sun, Aug 19, 2012 at 12:23:38PM +0200, Bjørn Mork wrote:
> Ming Lei <tom.leiming@xxxxxxxxx> writes:
> > On Fri, Aug 17, 2012 at 10:42 PM, Greg Kroah-Hartman
> > <gregkh@xxxxxxxxxxxxxxxxxxx> wrote:
> >> On Fri, Aug 17, 2012 at 10:38:16AM -0400, Alan Stern wrote:
> >>> On Fri, 17 Aug 2012, Ming Lei wrote:
> >>>
> >>> > But,  if HOTPLUG is not enabled, should device_add() trigger driver probe
> >>> > further after kernel init is completed?  Or even devices should be allowed
> >>> > to add into system?
> >>>
> >>> Indeed, does it make any sense to have USB support at all if HOTPLUG
> >>> isn't enabled?  Should USB select HOTPLUG?
> >>
> >> Well, a long time ago people wanted to use USB but not have HOTPLUG
> >> enabled in their systems for various (odd) embedded systems.  As it's
> >> pretty hard to even turn off HOTPLUG these days, I'd be more likely to
> >> just remove CONFIG_HOTPLUG entirely given the dynamic nature of almost
> >> all systems.
> >
> > It should make sense, otherwise all device id table should not use
> > __devinit* markings. There are lots of pci driver usage on it.
> 
> You might want to start here then:
> 
> /**
>  * DEFINE_PCI_DEVICE_TABLE - macro used to describe a pci device table
>  * @_table: device table name
>  *
>  * This macro is used to create a struct pci_device_id array (a device table)
>  * in a generic manner.
>  */
> #define DEFINE_PCI_DEVICE_TABLE(_table) \
>         const struct pci_device_id _table[] __devinitconst
> 

That's not as big of a problem, as pci drivers are usually left as a
module, and very few people dynamically add and remove pci devices on
systems that do not have CONFIG_HOTPLUG enabled.

Not to say that it couldn't happen, just that it is rare.

And it shows again that __devinitconst just needs to be removed, I'll
work on that soon and see what happens...

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