support for Intel Atom based QNAP LEDs/buttons/buzzer in Linux?

[Christoph Anton Mitterer]

Hi.

I wondered whether anyone knows, whether the kernel supports the
LEDs/buttons/buzzer of Intel Atom based QNAP NAS like the TS-569 Pro?

I got the two line LCD, which is a A125, working,...it can easily be
controlled via the serial device... but not the others.
Seems these are GPIO controlled...

I further found this: https://github.com/tomtastic/qnap-gpio/
but it seems it's for the TS-239 Pro only.

Any people out there with some experience? :)

Cheers and thanks,
Chris.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

[Christoph Anton Mitterer]

On Sat, 2013-06-15 at 03:31 +0200, Christoph Anton Mitterer wrote:
> I wondered whether anyone knows, whether the kernel supports the
> LEDs/buttons/buzzer of Intel Atom based QNAP NAS like the TS-569 Pro?

I tried to find out some more information (and got some help there as
well)... seems I'm stuck now, though. So perhaps for the records (and if
there should ever be someone with more experience in hardware
programming) what I found:



According[0] do Ian Campbell, who maintains qcontrol[1], the ARM based
QNAP devices have UART interface to their PIC controller (which
apparently controls the LEDs, buzzers, etc.)... it seems though that the
Intel based ones (or at least the one I have), doesn't have this - well
there is a serial device, but I guess it's just a "normal" one as
nothing happens when I send the (supposed) commands to it.

Actually I personally would have preferred being able to control the
stuff without the need for a kernel driver... a pity that I couldn't get
it running.


QNAP itself seems to have a kernel driver for all this...
On their website, they provide a GPL bundle[2], which, amongst others,
contains the sources to their kernel with many modifications (no single
patches provided, unfortunately o.O ).
This includes a drivers/qnap which seems to export a device /dev/pic
which their user space tools use to set the LEDs/etc. and that driver in
turn seems to use their modifications (GPIO stuff and so on) to the
kernel's it87 driver (according to Guenter - see below - they use a
IT8721).


I asked Guenter Roeck, who kindly had a look[3], but according to him,
the QNAP code cannot be easily taken over.


Well perhaps someone else with enough knowledge has time to look into
this,... or perhaps someone has some good contacts over at QNAP and is
able to lobby them to submit their code to the mainline kernel; I tried
to contact their support but got no answer.

Cheers,
Chris.


[0] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=712283
[1] https://gitorious.org/qcontrol/
[2] http://sourceforge.net/projects/qosgpl/files/latest/download
[3] https://github.com/groeck/it87/issues/1

[Greg KH]

On Thu, Jun 20, 2013 at 02:14:32AM +0200, Christoph Anton Mitterer wrote:
> Well perhaps someone else with enough knowledge has time to look into
> this,... or perhaps someone has some good contacts over at QNAP and is
> able to lobby them to submit their code to the mainline kernel; I tried
> to contact their support but got no answer.

If you can dig the code out into a stand-alone form that I can make into
a patch for the drivers/staging/ tree, I'll be glad to take it. Or, if
you get a contact at QNAP, I'll be glad to help out there as well, as
that's what we do all the time for loads of companies.

Good luck,

greg k-h

[Christoph Anton Mitterer]

Hey Greg.

On Wed, 2013-06-19 at 19:59 -0700, Greg KH wrote:
> If you can dig the code out into a stand-alone form that I can make into
> a patch for the drivers/staging/ tree, I'll be glad to take it.

Well I don't think my kernel/hardware development skills are enough for
that... especially as Guenter already said that the code shouldn't be
part of hwmon/it87 ... but rather a separate gpio driver...

> Or, if
> you get a contact at QNAP, I'll be glad to help out there as well

Well I've asked them again,... no reply so far.
The only direct contact I know (from the sources of their drivers) is
Wokes Wang, which I've CCed. Perhaps he can help.

> as
> that's what we do all the time for loads of companies.

sure...


Cheers,
Chris.

[Greg KH]

On Thu, Jun 20, 2013 at 11:28:26PM +0200, Christoph Anton Mitterer wrote:
> Hey Greg.
>
> On Wed, 2013-06-19 at 19:59 -0700, Greg KH wrote:
> > If you can dig the code out into a stand-alone form that I can make into
> > a patch for the drivers/staging/ tree, I'll be glad to take it.
> Well I don't think my kernel/hardware development skills are enough for
> that... especially as Guenter already said that the code shouldn't be
> part of hwmon/it87 ... but rather a separate gpio driver...

Fair enough.

> > Or, if
> > you get a contact at QNAP, I'll be glad to help out there as well
> Well I've asked them again,... no reply so far.
> The only direct contact I know (from the sources of their drivers) is
> Wokes Wang, which I've CCed. Perhaps he can help.

That would be great. Also, do you have a pointer to the git tree for
the hardware again, I can't seem to find it. I can dig through the tree
to see if I can make something "self-contained", if you are willing to
test it out.

thanks,

greg k-h

[Guenter Roeck]

On Thu, Jun 20, 2013 at 02:42:07PM -0700, Greg KH wrote:
> On Thu, Jun 20, 2013 at 11:28:26PM +0200, Christoph Anton Mitterer wrote:
> > Hey Greg.
> >
> > On Wed, 2013-06-19 at 19:59 -0700, Greg KH wrote:
> > > If you can dig the code out into a stand-alone form that I can make into
> > > a patch for the drivers/staging/ tree, I'll be glad to take it.
> > Well I don't think my kernel/hardware development skills are enough for
> > that... especially as Guenter already said that the code shouldn't be
> > part of hwmon/it87 ... but rather a separate gpio driver...
>
> Fair enough.
>

The best/cleanest option would be to have a mfd core driver for the IT87xx
variants and client drivers for hwmon, gpio, etc. Given that this might be
a bit complicated, another option would be to add gpio support into the
it87 driver itself. Unfortunately, I won't have time to do any of that.

What is worse is that the QNAP folks hacked the kernel all over the place.
There isn't just GPIO access added to the it87 driver (without using the gpio
subsystem), but platform initialization as well as code to access LEDs
and power buttonswere added to it as well. Overall they have hundreds of
patches on top of a 3.4.6 kernel. So we are not only talking about adding
support for the GPIO pins of IT87xx, and adding LED support as well as power
button handling on top of that, but about digging through a whole lot of
changes all over the place to find what is relevant.

The bad thing about it is really that many of the changes they made would be
beneficial to have in the upstream kernel, only it would probably take
man-years to clean it all up and get it there. Now the code isn't upstream,
they have a maintenance nightmare, and no one benefits from it :(.

Guenter

[Greg KH]

On Thu, Jun 20, 2013 at 11:56:34PM +0200, Christoph Anton Mitterer wrote:

> On Thu, 2013-06-20 at 14:42 -0700, Greg KH wrote:
> > Also, do you have a pointer to the git tree for
> > the hardware again, I can't seem to find it.

> You mean a git repo for their driver? I don't think they have one...
> just the big tarball with the patches integrated...

Ick, nevermind, it sounds like a mess to unwind, I'll wait for the
company to do it properly, sorry.