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.
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
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
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.
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
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...
> I can dig through the tree
> to see if I can make something "self-contained", if you are willing to
> test it out.
Sure... I'm happy to test anything out... right now the box isn't used
in production yet... so it's easy for me... and I guess you have enough
experience to not accidentally write code that overwrites the
firmware ;) (which would probably happen when I'd have tried to ^^)
Thanks,
Chris.
btw: Let's remove Wokes Wang again in any following messages... if he's
interested in contributing he can come back and read the messages in the
archive (http://thread.gmane.org/gmane.linux.kernel/1508763)... and I
don't want to spam him, if he's not interested.
Oh and one more thing:
The QNAP driver seems to be able to do much more than just
LEDs/HDD-LEDs/buzzers/buttons... at least their symbols imply such,
like:
#define QNAP_IOCTL_SATA_UP 0x0100
#define QNAP_IOCTL_SATA_DOWN 0x0200
#define QNAP_IOCTL_ESATA_UP 0x0300
#define QNAP_IOCTL_ESATA_DOWN 0x0400
#define QNAP_IOCTL_SATA_ERR 0x0500
#define QNAP_IOCTL_ETH_UP 0x0600
#define QNAP_IOCTL_ETH_DOWN 0x0700
#define QNAP_IOCTL_BOND_UP 0x0800
#define QNAP_IOCTL_BOND_DOWN 0x0900
#define QNAP_IOCTL_USB_DRV_RELOAD 0x0a00
#define QNAP_IOCTL_USB_SET_POLL_INTV 0x0b00
#define MD_RESYNCING 0x20
#define MD_RESYNCING_DONE 0x21
#define MD_RESYNCING_SKIP 0x22
#define MD1_REBUILDING 0x23
#define MD1_REBUILDING_DONE 0x24
#define MD1_REBUILDING_SKIP 0x25
#define MD1_RESYNCING 0x26
...
and much more (see drivers/qnap/pic.h of their kernel bundle).
I'm not sure whether it would be really a good idea for the end user to
use all these... the "normal" kernel drivers seem to handle all that
just fine.
Same applies for the cooling fan... there are PIC commands to control
it... (with my TS 569 Pro,... that didn't even work from within the
native QNAP firmware)... but fancontrol from lm-sensor already works
fine (any much more granular)... so I guess people should use that...
and it's not needed to add suport for that as well.
When you look at the model that I have (the TS-569 Pro[0]):
http://www.qnap.com/upload/album/24/m_929_20120726112135_59189.png
- The LCD already works, is a A125 device and controllable via an UART.
- The power button already works (normal ACPI button device)
- The buzzer does not yet work.
- With respect to the LEDs... from the native QNAP firmware I was able
to control the left-most one[1] (below the QNAP logo) and the ones
labelled STATUS[2] and USB[3].
- I'm not sure whether one can control the HDD-LEDs at all (but I'd hope
so[4])
- The other 3 buttons (in the image labelled COPY, ENTER, SELECT) do all
not work.
qcontrol (on some ARM based QNAPs) does a bit more and also allows to
set EuP mode and WOL...
One thing that could be interesting was, if it were possible really
power down SATA ports... could perhaps be QNAP_HDERR_ON(nr) /
QNAP_HDERR_OFF(nr)... or QNAP_SATAn_UP / QNAP_SATAn_DOWN ... but that's
just blind guessing.
Best wishes,
Chris.
[0]
http://www.qnap.com/useng/index.php?lang=en-us&sn=862&c=355&sc=526&t=692&n=9904
[1] These are the QNAP_PIC_POWER_LED_* in their code.
[2] These are the QNAP_PIC_STATUS_* in their code.
[3] These are the QNAP_PIC_USB_LED_* in their code.
[4] There is IOCTL_HD_ERROR_LED_SEND_MESSAGE and int
set_hd_error_led_on(int, int) in their code, which could be that.
[5] QNAP_PIC_WOL_* and QNAP_PIC_EUP_*
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
> > > 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
>
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.
greg k-h
Hi Greg, Guenter and Chris.
Coming back to the stuff discussed previously[0].
Chris Eastwood has made most of these (i.e. LEDs and buttons, the
buzzers may work on at least some of the devices via some other serial
device) working (AFAIU based on the previously mentioned code at
Github[1]), he told me in several iterations of private mail.
I'm not sure now, whether anything based on this code would be
appropriate for the mainline kernel, since Guenter mentioned he'd prefer
a mfd core driver for all that... OTOH, the later may probably never
happen, and Chris' work seems to already do the job.
I don't know however, whether he needs to patch any other places in the
kernel, but I'm sure he can show his work (and ask questions) better
than I, thereby inviting him to do so.
Greg you had mentioned before that you might be able to spend some time
on this, so if you could help Chris, that would be great.
Cheers,
Chris.
[0] http://thread.gmane.org/gmane.linux.kernel/1508763/focus=1512903
[1] https://github.com/tomtastic/qnap-gpio/
PS: Sorry for having lost the message threading.
On 10/13/2013 04:46 PM, Christoph Anton Mitterer wrote:
> Hi Greg, Guenter and Chris.
>
> Coming back to the stuff discussed previously[0].
>
> Chris Eastwood has made most of these (i.e. LEDs and buttons, the
> buzzers may work on at least some of the devices via some other serial
> device) working (AFAIU based on the previously mentioned code at
> Github[1]), he told me in several iterations of private mail.
>
> I'm not sure now, whether anything based on this code would be
> appropriate for the mainline kernel, since Guenter mentioned he'd prefer
> a mfd core driver for all that... OTOH, the later may probably never
> happen, and Chris' work seems to already do the job.
>
> I don't know however, whether he needs to patch any other places in the
> kernel, but I'm sure he can show his work (and ask questions) better
> than I, thereby inviting him to do so.
> Greg you had mentioned before that you might be able to spend some time
> on this, so if you could help Chris, that would be great.
>
>
You really have two options - either an mfd driver with client drivers
for hwmon, gpio, watchdog (and possibly others), or a gpio driver which
shares access to the superio control registers. Both the it87 hwmon driver
and the it87 watchdog driver support the latter mechanism already, so that
would be the (much) simpler option. To control the LEDs you would then
simply use the leds-gpio driver. Input would need something similar -
no idea if there is a generic input-gpio driver; if not it might make sense
to write one. Another option there would be to have a platform driver which
would tie into the gpio driver and pass the gpio pin status to the input
subsystem.
I had a look at Chris' driver, but in my opinion it is simply too hardware
specific to be acceptable as-is. Of course, I would not make the call,
so that is just my persional opinion.
Thanks,
Guenter
On 10/14/2013 12:29 AM, Chris Eastwood wrote:
>
> Hi all, nice to meet you and thank you for replying Guenter,
>
> The code you are talking about wasn't actually written by me, and I have been unable to get hold of the author; I have just been recompiling it to see what I can do with it.
>
> I have found that the GPIO driver is able to control the following LEDs:
>
> Power LED (green)
> Status LED (green, red)
> USB LED (blue)
> 8 HDD LEDs (*red only)
> /(and the USB copy button)/
>
> It does not appear to be able to control the *green *HDD LEDs though
>
> I found that the *green* HDD LEDs can be enabled through */drivers/ata/libata-scsi.c* by including a new function, here is what I took from qnap's source:
>
> #define SGPIO_RETRY_MAX 15
> static void ata_port_led(struct ata_port *ap,u8 on)
> {
> int rc = 0;
> int retry=0;
> if (ap->ops->em_store && (ap->flags & ATA_FLAG_EM)){
> for(retry = 0 ; retry < SGPIO_RETRY_MAX ; retry++){
> rc = ap->ops->em_store(ap, on ? "0x80000" : "0x0", 4);
> if (rc == -EBUSY)
> udelay(100);
> else
> break;
> }
> }
> if(retry == SGPIO_RETRY_MAX)
> printk("%s:SGPIO always busy\n",__func__);
> }
>
>
> Which is then called from the following two locations:
>
>
> *void ata_scsi_scan_host(struct ata_port *ap, int sync)*
> *{*
> * ...*
> *if (!IS_ERR(sdev)) {*
> ata_port_led(ap,1);
> * ...*
> * }*
> * ...*
> *}*
>
>
> *static void ata_scsi_remove_dev(struct ata_device *dev)*
> *{*
> * ...*
> * if (sdev) {*
> ata_port_led(ap,0);
> * ...*
> * }*
> *}*
> *
> *
> Once booting the newly compiled kernel the green HDD LEDs are working and blinking correctly.
>
> What are your thoughts on the green HDD LEDs ?
>
It appears the LED is supposed to be controlled from userspace, possibly
with a udev rule or script.
There is a sysfs attribute which should be used for this purpose.
Search for "em_message" on /sys. Writing '0x80000' (as text) should turn
the LED on, writing '0x0' should turn it off. The attribute supports other
values as well. Search for "Enclosure Management LED Message Type" in the
kernel source.
Thanks,
Guenter
> Thank you!
>
> Chris
>
>
>
> On 14 October 2013 11:19, Guenter Roeck <[email protected] <mailto:[email protected]>> wrote:
>
> On 10/13/2013 04:46 PM, Christoph Anton Mitterer wrote:
>
> Hi Greg, Guenter and Chris.
>
> Coming back to the stuff discussed previously[0].
>
> Chris Eastwood has made most of these (i.e. LEDs and buttons, the
> buzzers may work on at least some of the devices via some other serial
> device) working (AFAIU based on the previously mentioned code at
> Github[1]), he told me in several iterations of private mail.
>
> I'm not sure now, whether anything based on this code would be
> appropriate for the mainline kernel, since Guenter mentioned he'd prefer
> a mfd core driver for all that... OTOH, the later may probably never
> happen, and Chris' work seems to already do the job.
>
> I don't know however, whether he needs to patch any other places in the
> kernel, but I'm sure he can show his work (and ask questions) better
> than I, thereby inviting him to do so.
> Greg you had mentioned before that you might be able to spend some time
> on this, so if you could help Chris, that would be great.
>
>
> You really have two options - either an mfd driver with client drivers
> for hwmon, gpio, watchdog (and possibly others), or a gpio driver which
> shares access to the superio control registers. Both the it87 hwmon driver
> and the it87 watchdog driver support the latter mechanism already, so that
> would be the (much) simpler option. To control the LEDs you would then
> simply use the leds-gpio driver. Input would need something similar -
> no idea if there is a generic input-gpio driver; if not it might make sense
> to write one. Another option there would be to have a platform driver which
> would tie into the gpio driver and pass the gpio pin status to the input
> subsystem.
>
> I had a look at Chris' driver, but in my opinion it is simply too hardware
> specific to be acceptable as-is. Of course, I would not make the call,
> so that is just my persional opinion.
>
> Thanks,
> Guenter
>
>
