H Dmitry, On 2020-05-06 9:23 p.m., Dmitry Torokhov wrote: > On Wed, May 06, 2020 at 08:46:12PM -0700, Jonathan Bakker wrote: >> Hi Linus, >> >> On 2020-05-06 5:46 a.m., Linus Walleij wrote: >>> On Sun, May 3, 2020 at 7:22 PM Jonathan Bakker <xc-racer2@xxxxxxx> wrote: >>> >>>> The bma180 IIO driver has been extended for support for bma023. >>>> However, this could cause conflicts with this driver. Since some >>>> setups may depend upon the evdev setup, disable support in this >>>> driver for the bma023 only when the IIO driver is being built. >>>> >>>> Signed-off-by: Jonathan Bakker <xc-racer2@xxxxxxx> >>> >>> I would just fix this with KConfig instead, like add mutually >>> exclusive depends on these two drivers. >>> >>> Set this input driver as: >>> depends on BMA180=n >>> >>> And the IIO driver as: >>> depends on INPUT_BMA150=n >>> >>> It's a rough measure but this input driver should anyway >>> go away. > > Isn't the driver handle more than bma023? I see bma150 and smb380 ID's. > If we go Kconfig route we will be disabling it for them as well when IIO > driver is enabled. > Yes, that's correct. >>> >> >> Ok, sounds good to me. If I include a patch removing the input >> driver, can I just drop this patch entirely? > >> >> The only in-tree user of the input driver (based on i2c ids) is Intel >> Mid. Not sure what the kernel policy on dropping drivers is. > > Do we still support this platform? I'd start there. It looks to me like the preferred method would be to also add IIO support for smb380/bma150, add the exclusive Kconfig entries, and leave the input driver in place. Does this work for everyone? > > Thanks. > Thanks, Jonathan
