[Letux-kernel] two accelerometers + iio_bridge considered harmful

H. Nikolaus Schaller hns at goldelico.com
Wed Aug 1 16:53:42 CEST 2018

> Am 01.08.2018 um 16:38 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Wed, 1 Aug 2018 09:14:58 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> Hi,
>>> Am 01.08.2018 um 08:22 schrieb H. Nikolaus Schaller <hns at goldelico.com>:
>>>> So first question is it really worth to make it thread-safe
>>> Well, a simple mutex would help.
>>> But where could we initialize it before the first channel is registered?
>>> And make sure that it is initialized only once (without another mutex)?
>> Ah, it is easy. DEFINE_MUTEX is a static initializer :)
>> Attached is a new patch which does not break my devices (except rmmod, see
>> below - this might be if channels[0].data is no longer valid) and may help
>> in your setup. Please let me know your results.
> Ok, tried it partly, I did a patch -p1 directly on top of my current source
> including the additional debug outputs to not accidentially hide problems.
> Only the channel mutex stuff applied. I moved the channel_mutex declaration behind the input_work declaration so channels[3] will still point to the input_work if the
> compiler is not in a mood to reorder things.

Maybe it works better if you

git checkout -B temp letux-4.something
git am *.patch
git cherry pick your patches for debugging

Alternatively you could try to git merge the result after git am
into your debgging tree.

Still both approaches may show merge conflicts.

> I do not see the race on my two affected filesystems,
> neither on stretch nor on jessie.

That is good.

> But it is still strange why
> you do not see the race at all.

Well, races depend on timing. Timing depends on multiple factors, i.e.
other devices to come up, PLLs to stabilize, speed of SD card, time for udev
to locate the kernel module etc...

> And something in probing must have changed in 4.18.
> Someone must have smuggled a if (latitiude > 50) into the gnss code ;-)


> Another thing to analyze is whether we might get
> X from accel 1, X from accel 2 and Y from accel 1.
> I have not tested that yet.

I have added the check that all axis are coming from the same device.

> I think we should clearly have one input device per iio accelerometer device,
> that might probably save us some trouble.

Yes, it is more logical. I am just not sure which data structure to use.
Maybe we need a global radix tree to map from iio devices to the input devices.
The reverse direction could be done by .data pointers. But I am not sure
if they exists. Or we need two trees for both mapping directions. And we need
to store the iio channel pointers (note that we can't simply scan the iio device
in the polling worker because there may be non-accel iio channels in a chip).


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.goldelico.com/pipermail/letux-kernel/attachments/20180801/e9d6b2df/attachment.asc>

More information about the Letux-kernel mailing list