| Message ID | BN6PR04MB0660B420EFA83668BBF4F315A3A90@BN6PR04MB0660.namprd04.prod.outlook.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | iio: accel: Add bma023 support to bma180 | expand |
On Sun, May 3, 2020 at 7:22 PM Jonathan Bakker <xc-racer2@live.ca> 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@live.ca> 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. Yours, Linus Walleij
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@live.ca> 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@live.ca> > > 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. > 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. > Yours, > Linus Walleij > Thanks, Jonathan
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@live.ca> 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@live.ca> > > > > 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. > > > > 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. Thanks.
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@live.ca> 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@live.ca> >>> >>> 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
On Fri, May 8, 2020 at 5:57 PM Jonathan Bakker <xc-racer2@live.ca> wrote: > 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? That's my preferred solution for sure, so go for it if I have a say. Yours, Linus Walleij
diff --git a/drivers/input/misc/bma150.c b/drivers/input/misc/bma150.c index a9d984da95f3..5d3f8b05b316 100644 --- a/drivers/input/misc/bma150.c +++ b/drivers/input/misc/bma150.c @@ -541,7 +541,10 @@ static UNIVERSAL_DEV_PM_OPS(bma150_pm, bma150_suspend, bma150_resume, NULL); static const struct i2c_device_id bma150_id[] = { { "bma150", 0 }, { "smb380", 0 }, + /* Prefer the IIO-based driver for bma023 if enabled */ +#if !IS_ENABLED(CONFIG_BMA180) { "bma023", 0 }, +#endif { } };
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@live.ca> --- drivers/input/misc/bma150.c | 3 +++ 1 file changed, 3 insertions(+)