[Letux-kernel] Request for tasks
H. Nikolaus Schaller
hns at goldelico.com
Sat May 28 13:30:56 CEST 2016
> Am 28.05.2016 um 00:50 schrieb Andrey Utkin <andrey_utkin at fastmail.com>:
> I have checked http://projects.goldelico.com/p/gta04-kernel/issues/ ,
> but I find the descriptions too brief for a newcomer to understand. They
> are good as a memorisation notes for who have written them, though :)
Well, that is the main purpose of the issue tracker so far :)
So let's improve on that...
In total there are only ~10-12 of them relevant for the Pyra. Several others are
for the GTA04 hardware. BTW, we will have a kernel hacking workshop next
weekend in Munich to address some of them.
> So I'd like to ask for 2-3 issues which are still actual and important
> (to avoid looking at outdated tickets), but which are not on a priority
> list of other developers, so that I don't hijack somebody's task. I
> don't know yet which amount of spoon-feeding I would need - I hope very
> little of it - but still if it's something about any chips, I'd need
> access to datasheets;
Yes, I am preparing a download server where also NDA covered data
sheets can be made available to trusted participants.
> if it's about mainlining, then I'd need a context
> - whether it was pushed before, which were rejection reasons, etc.
You can find some of these discussions in the letux-kernel archive (started in February):
Rejection reasons are sometimes difficult to grasp. For example for our
bluetooth power-automatic driver (called uart-slaves) the official MAINTAINERS
didn't comment. Except Alan Cox (hidden behind a synonym) and complained
how difficult it is to change anything in the tty stack, turning around any
word I wrote, and finally "plonking" me. So there was no fruitful discussion
at all... Sometimes people complained and asked to shut up, instead of
giving technical reasons or answering a request for a requirements or
style-guide document. So the rejection reason might be that I pointed out
lack of concept on maintainers side but they could only say that my proposal
doesn't fit into their vague concepts. But they were not able to describe it to me
in textbook quality.
> Actually I think mainlining tasks would require less of load on you, as
> I'm not proficient on hardware, but experienced on LKML review process.
Well, the key problem of the LKML review process is that you have something
working and well thought - but one of the thoughts is not accepted or understood
by maintainers. This means turning the code upside down and expand what had
been clean :)
This may take much more time than anticipated and needs to stay focussed
on collecting feedbacks. And working them in. So it might be 30% of total efforts
to get something working and 70% to get it accepted.
Anyways that is something we have to go through.
The last driver I submitted to LMKL is the is31fl319x driver. I already got a lot of feedback
and prepared a V2:
But one significant change hasn't been worked in (because ours works equally well).
They suggested to use some very new features of the gpiolib to get rid of locking in the
driver. I generally would prefer that as well but testing locking (and debugging if it does not
work) is extremely time consuming (and needs hardware to test on).
So generally I think this is probably not the right phase to jump in and take over.
Perhaps after I fixed what I already got as feedback and submitted again. Then, you
can already participate in the discussion and it might be much easier to understand
the LKML feedbacks than if I try to summarise...
But there are also work packages for new drivers where nobody did take care so far.
We have these sensor chips:
* or BNO055
For some we don't have any or good enough (iio) drivers. Bosch Sensortec has some
libraries. And there are drivers for similar chips. So that could be a topic where you can
start from scratch and proceed in your own pace. And they are not too complex to start with.
Another (almost) unprocessed task is the eMMC/µSD-Switch which IMHO should get a
driver that can switch between both on demand. My work so far is just a bindings document
to describe how *I* think it could be integrated into the DT. This is
and branch http://git.goldelico.com/?p=gta04-kernel.git;a=shortlog;h=refs/heads/work/hns/mmc/txs02612
Generally it is a little difficult to advise which issues to address next/best. More will come
up as more hardware is built and distributed.
Hopefully I have not written too much and made it look more complex than it is :)
More information about the Letux-kernel