Your message dated Sun, 25 Apr 2021 08:59:05 +0200 with message-id <YIUTOZIA4zlZT++O@eldamar.lan> and subject line Re: Bug#752697: Activity LED on SiI-3112A PCI SATA card does not work has caused the Debian Bug report #752697, regarding Activity LED on SiI-3112A PCI SATA card does not work to be marked as done. This means that you claim that the problem has been dealt with. If this is not the case it is now your responsibility to reopen the Bug report if necessary, and/or fix the problem forthwith. (NB: If you are a system administrator and have no idea what this message is talking about, this may indicate a serious mail system misconfiguration somewhere. Please contact owner@bugs.debian.org immediately.) -- 752697: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=752697 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
--- Begin Message ---
- To: submit@bugs.debian.org
- Subject: Activity LED on SiI-3112A PCI SATA card does not work
- From: "dilieto@lineone.net" <dilieto@lineone.net>
- Date: Wed, 25 Jun 2014 19:34:14 +0100 (BST)
- Message-id: <6864127.721681403721254061.JavaMail.defaultUser@defaultHost>
Package: linux-image-3.2.0-4-686-pae Version: 3.2.57-3+deb7u2 The activity LED on my SiI3112A PCI SATA card does not work. The SiI chip on this family of cards has no dedicated LED pin, therefore the activity LED is commonly implemented with a 74HC00 quad-NAND chip connected as a SR flip-flop to the Write/Read flash strobe lines. The LED is turned on (or off) by transferring a byte to (or from) the flash chip. When transferring to the flash chip the write goes to the command register. A reset command is safe to send, as it just puts the flash chip in read mode (which is the default anyway). In particular, there is zero risk of actually writing to flash - this can happen only after the proper unlock sequence is sent. I have implemented and tested successfully a new "enable_led" parameter for the sata_sil module. The new parameter is zero (meaning disabled) by default. Therefore the behaviour of existing installations will not change unless explicitly enabled. I would appreciate if this could be integrated in the official package. With kind regards NickAttachment: sata_sil_led.patch.gz
Description: GNU Zip compressed data
--- End Message ---
--- Begin Message ---
- To: "dilieto@lineone.net" <dilieto@lineone.net>, 752697-done@bugs.debian.org
- Subject: Re: Bug#752697: Activity LED on SiI-3112A PCI SATA card does not work
- From: Salvatore Bonaccorso <carnil@debian.org>
- Date: Sun, 25 Apr 2021 08:59:05 +0200
- Message-id: <YIUTOZIA4zlZT++O@eldamar.lan>
- In-reply-to: <6864127.721681403721254061.JavaMail.defaultUser@defaultHost>
- References: <6864127.721681403721254061.JavaMail.defaultUser@defaultHost>
Hi, On Wed, Jun 25, 2014 at 07:34:14PM +0100, dilieto@lineone.net wrote: > Package: linux-image-3.2.0-4-686-pae > Version: 3.2.57-3+deb7u2 > > The > activity LED on my SiI3112A PCI SATA card does not work. > > The SiI chip > on this family of cards has no dedicated LED pin, therefore the > activity LED is commonly implemented with a 74HC00 quad-NAND chip > connected as a SR flip-flop to the Write/Read flash strobe lines. The > LED is turned on (or off) by transferring a byte to (or from) the flash > chip. > > When transferring to the flash chip the write goes to the > command register. A reset command is safe to send, as it just puts the > flash chip in read mode (which is the default anyway). In particular, > there is zero risk of actually writing to flash - this can happen only > after the proper unlock sequence is sent. > > I have implemented and > tested successfully a new "enable_led" parameter for the sata_sil > module. > > The new parameter is zero (meaning disabled) by default. > Therefore the behaviour of existing installations will not change > unless explicitly enabled. > > I would appreciate if this could be > integrated in the official package. If this is still an issue, then please do report this upstream, we do want to diverge as less as necessary from upstream. I'm inclined to close this bugreport now, given it's age and the kernel it was reported against. Feel free to reopen if the issue is still present (but see the note above). Regards, Salvatore
--- End Message ---