[Letux-kernel] [PATCH letux] panel-boe-w667l: hack-fix disapble oopses
H. Nikolaus Schaller
hns at goldelico.com
Sat Dec 1 12:46:24 CET 2018
> Am 01.12.2018 um 12:38 schrieb Andreas Kemnade <andreas at kemnade.info>:
> On Sat, 1 Dec 2018 09:36:43 +0100
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> Hi Andreas,
>>> Am 01.12.2018 um 09:04 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> panel-dsi-cm also seems not to do in->opes->disable(),
>>> so maybe it should really be removed.
>> Yes, that should be right.
>> There are two aspects:
>> 1. calling in->ops->disable is (was?) needed when chaining the panel behind the ssd2258 rotator chip so that it is informed about panel disable
>> 2. there was a big change in 4.20-rc1 how in and in->ops are set up and passed down to panel drivers
>> The panel-dsi-cm is not prepared for such encoder chaining.
>> So it might or might not be necessary to keep it. All this is something which I wasn't able to debug so far.
>> Of course we should not call in->ops->disable if in->ops == NULL :)
> well, being able to enable something and then not being able to disable
> it is highly counter-intuitive.
Of course. But all this is the result of trying to fix all problems introduced
by upstream changes in the core...
Up to 4.19 there was no in-ops bot a different struct pointer sequence that never was NULL.
BTW: this is where I sometimes think we should develop a tool similar to ELIXIR but not
to be able to click through functions but through all kernel structs and dereferences...
It is sometimes quite mind-mangling and time consuming to track down and understand all
these struct pointers. Especially if they change between kernel releases.
Alternatively, Linux should be rewritten in a good object oriented language which is what
all these op-pointer structs try to mimick :)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 801 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the Letux-kernel