On Mon, Oct 02, 2017 at 12:00:54PM +0300, Jani Nikula wrote: > On Mon, 02 Oct 2017, Daniel Thompson <daniel.thompson@xxxxxxxxxx> wrote: > > So I'm coming to this patchset cold but can you explain *why* something > > wants to call of_find_backlight_by_node() when there is no backlight > > support enabled. Why isn't the code that called is conditional on > > BACKLIGHT_CLASS_DEVICE? > > > > The undefined symbol issue is a pain but to be honest I'd rather solve > > the use of undefined symbols by avoiding declaring them; this making > > them into compile errors rather than link errors. > > Typically the kernel header files define static inline stubs of the > functions when the actual functions aren't configured/built. The code > using the functions looks the same regardless of the config option, and > handles the -ENODEV or NULL or whatever returns from the stubs > gracefully. With the inlines, the compiler can usually throw out much of > the code anyway. > > In this regard, the backlight interface is an exception, forcing the > callers to wrap the code around IS_ENABLED(BACKLIGHT_CLASS_DEVICE), not > the rule. fwiw, I think it'd be great if we can move backlight over to the common pattern, like everyone else. It's pretty big pain as-is ... -Daniel -- Daniel Vetter Software Engineer, Intel Corporation http://blog.ffwll.ch _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
