From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754792AbcDNJJU (ORCPT ); Thu, 14 Apr 2016 05:09:20 -0400 Received: from smtp.nue.novell.com ([195.135.221.5]:41197 "EHLO smtp.nue.novell.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753378AbcDNJJR (ORCPT ); Thu, 14 Apr 2016 05:09:17 -0400 Subject: Re: [PATCH v2] ata: add AMD Seattle platform driver To: Brijesh Singh , Arnd Bergmann , Tejun Heo References: <1452789071-4090-1-git-send-email-brijesh.singh@amd.com> <5709817.yQT8N3CaLj@wuerfel> <20160316210713.GI21104@mtj.duckdns.org> <31951835.kMFH9CgruZ@wuerfel> <56EC4AB8.7040901@amd.com> Cc: linux-kernel@vger.kernel.org, hdegoede@redhat.com, linux-ide@vger.kernel.org, Graeme Gregory From: Matthias Brugger Message-ID: <570F5E14.9020403@suse.com> Date: Thu, 14 Apr 2016 11:08:36 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 MIME-Version: 1.0 In-Reply-To: <56EC4AB8.7040901@amd.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Brijesh, On 18/03/16 19:36, Brijesh Singh wrote: > Hi Tejun, > > On 03/17/2016 12:36 PM, Arnd Bergmann wrote: >> On Wednesday 16 March 2016 14:07:13 Tejun Heo wrote: >>> Hello, Arnd. >>> >>> On Mon, Feb 01, 2016 at 09:14:17PM +0100, Arnd Bergmann wrote: >>>>> I am not debating on your AML call recommendation, it sounds like >>>>> a good idea however BIOS is already released hence its bit late to >>>>> add AML methods for this. I am seeking guidance on what can be >>>>> done in the given situation. I thought platform driver is one >>>>> option to get this feature enabled in kernel. >>> >>>> This is where we really need the ACPI maintainers to explain the >>>> general policy for dealing with firmware updates. >>>> >>>> I would assume that adding the feature in a later firmware version >>>> is a compatible change, and the feature is non-essential (the >>>> device will work fine with the generic SATA driver, except >>>> the LEDs don't blink), so it's not a big deal, it's just what >>>> you get for having the firmware shipped before the driver is >>>> reviewed (don't do that). >>> >>> So, if it were x86, I'd commit the custom driver without thinking too >>> much as ata drivers have always been working around bios issues (there >>> often wasn't any other recourse). If the hardware is already out >>> there and it's not too easy to roll out bios updates, from libata >>> side, I'm okay with having a custom driver to work around that. What >>> do you think? >> >> >> It's your call in the end. My main objection is to the fact that >> I have suggested a clean implementation for the normal DT based >> path that also fixes existing platforms that used to work in the >> past and were broken by the (long-ago) move from drivers/ide to >> drivers/ata, Brijesh has not implemented that but has instead >> continued pushing the hack for the ACPI mode that is still >> experimental on ARM64. >> > > I am helping a customer who want EM support in a distro (using ACPI mode). Since its difficult to update > the bios hence can I request to pull this driver. The driver solves the ACPI usecases. > > As per DT is concerned, will look into driver/ide and led framework but since I am not very familiar with > driver/ide and led framework hence it will take sometime to design and implement the DT cases. > Did you made any progress on the DT part? Regards, Matthias