Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.kernel > #1317287 > unrolled thread
| Started by | Tejun Heo <tj@kernel.org> |
|---|---|
| First post | 2016-01-25 21:50 +0100 |
| Last post | 2016-01-26 13:20 +0100 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.kernel
This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by
below is the oldest one visible, not the original post.
Re: [PATCH v2] ata: add AMD Seattle platform driver Tejun Heo <tj@kernel.org> - 2016-01-25 21:50 +0100
Re: [PATCH v2] ata: add AMD Seattle platform driver Hans de Goede <hdegoede@redhat.com> - 2016-01-26 10:40 +0100
Re: [PATCH v2] ata: add AMD Seattle platform driver Arnd Bergmann <arnd@arndb.de> - 2016-01-26 13:20 +0100
| From | Tejun Heo <tj@kernel.org> |
|---|---|
| Date | 2016-01-25 21:50 +0100 |
| Subject | Re: [PATCH v2] ata: add AMD Seattle platform driver |
| Message-ID | <qUWfg-12K-5@gated-at.bofh.it> |
On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote: > AMD Seattle SATA controller mostly conforms to AHCI interface with some > special register to control SGPIO interface. In the case of an AHCI > controller, the SGPIO feature is ideally implemented using the > "Enclosure Management" register of the AHCI controller, but those > registeres are not implemented in the Seattle SoC. Instead SoC > (Rev B0 onwards) provides a 32-bit SGPIO control register which should > be programmed to control the activity, locate and fault LEDs. > > The driver is based on ahci_platform driver. > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > Acked-by: Hans de Goede <hdegoede@redhat.com> > CC: tj@kernel.org > CC: linux-ide@vger.kernel.org Hans, can you please review the patch? Thanks. -- tejun
[toc] | [next] | [standalone]
| From | Hans de Goede <hdegoede@redhat.com> |
|---|---|
| Date | 2016-01-26 10:40 +0100 |
| Message-ID | <qV8gr-28S-25@gated-at.bofh.it> |
| In reply to | #1317287 |
Hi, On 25-01-16 21:43, Tejun Heo wrote: > On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote: >> AMD Seattle SATA controller mostly conforms to AHCI interface with some >> special register to control SGPIO interface. In the case of an AHCI >> controller, the SGPIO feature is ideally implemented using the >> "Enclosure Management" register of the AHCI controller, but those >> registeres are not implemented in the Seattle SoC. Instead SoC >> (Rev B0 onwards) provides a 32-bit SGPIO control register which should >> be programmed to control the activity, locate and fault LEDs. >> >> The driver is based on ahci_platform driver. >> >> Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> >> Acked-by: Hans de Goede <hdegoede@redhat.com> >> CC: tj@kernel.org >> CC: linux-ide@vger.kernel.org > > Hans, can you please review the patch? Done, driver looks good to me: Acked-by: Hans de Goede <hdegoede@redhat.com> Regards, Hans
[toc] | [prev] | [next] | [standalone]
| From | Arnd Bergmann <arnd@arndb.de> |
|---|---|
| Date | 2016-01-26 13:20 +0100 |
| Message-ID | <qVaLg-3XS-11@gated-at.bofh.it> |
| In reply to | #1317287 |
On Monday 25 January 2016 15:43:00 Tejun Heo wrote: > On Thu, Jan 14, 2016 at 10:31:11AM -0600, Brijesh Singh wrote: > > AMD Seattle SATA controller mostly conforms to AHCI interface with some > > special register to control SGPIO interface. In the case of an AHCI > > controller, the SGPIO feature is ideally implemented using the > > "Enclosure Management" register of the AHCI controller, but those > > registeres are not implemented in the Seattle SoC. Instead SoC > > (Rev B0 onwards) provides a 32-bit SGPIO control register which should > > be programmed to control the activity, locate and fault LEDs. > > > > The driver is based on ahci_platform driver. > > > > Signed-off-by: Brijesh Singh <brijesh.singh@amd.com> > > Acked-by: Hans de Goede <hdegoede@redhat.com> > > CC: tj@kernel.org > > CC: linux-ide@vger.kernel.org > > Hans, can you please review the patch? > I think it needs more work: The changelog describes it as a normal driver, but based on the previous discussion, this is just a hack to work around broken BIOS versions that can no longer be fixed in the field, and there has not been a decision what the proper representation should be in ACPI. The patch also fails to address the devicetree based case, even though we did come to a conclusion that the current behavior is a regression (compared to what we had in drivers/ide/) and that there is a relatively simple fix to do it right. I'd rather see this problem solved for DT first and then have a discussion about what the ACPI binding should look like, with a review from ACPI folks before this hack gets cemented in the kernel. Arnd
[toc] | [prev] | [standalone]
Back to top | Article view | linux.kernel
csiph-web