Re: [PATCH 2/5] input: misc: bma150: Conditionally disable bma023 support

[Jonathan Bakker]

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