linux-kernel - Re: [PATCH v2] ata: add AMD Seattle platform driver

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Jan 2016 13:17:16 +0100
From:	Arnd Bergmann <arnd@...db.de>
To:	Tejun Heo <tj@...nel.org>
Cc:	Brijesh Singh <brijesh.singh@....com>,
	linux-kernel@...r.kernel.org, hdegoede@...hat.com,
	linux-ide@...r.kernel.org
Subject: Re: [PATCH v2] ata: add AMD Seattle platform driver

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@....com>
> > Acked-by: Hans de Goede <hdegoede@...hat.com>
> > CC: tj@...nel.org
> > CC: linux-ide@...r.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