From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received-SPF: Pass (sender SPF authorized) identity=mailfrom; client-ip=134.134.136.20; helo=mga02.intel.com; envelope-from=ruiyu.ni@intel.com; receiver=edk2-devel@lists.01.org Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ml01.01.org (Postfix) with ESMTPS id B2F6F222CF1CB for ; Wed, 10 Jan 2018 18:20:05 -0800 (PST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by orsmga101.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Jan 2018 18:25:18 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.46,342,1511856000"; d="scan'208";a="193914359" Received: from ray-dev.ccr.corp.intel.com (HELO [10.239.9.19]) ([10.239.9.19]) by fmsmga005.fm.intel.com with ESMTP; 10 Jan 2018 18:25:17 -0800 To: Ard Biesheuvel , Udit Kumar Cc: Meenakshi Aggarwal , "edk2-devel@lists.01.org" , "Zeng, Star" , "leif.lindholm@linaro.org" References: <1515410208-14559-1-git-send-email-meenakshi.aggarwal@nxp.com> <1515410208-14559-2-git-send-email-meenakshi.aggarwal@nxp.com> <4ea591d7-5218-d174-7fde-90ecf8a76f02@Intel.com> From: "Ni, Ruiyu" Message-ID: <6e0dbabe-a688-62cd-7600-31c497674610@Intel.com> Date: Thu, 11 Jan 2018 10:25:16 +0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: Subject: Re: [RFC] SATA : Implemented NXP errata A008402 X-BeenThere: edk2-devel@lists.01.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: EDK II Development List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Jan 2018 02:20:06 -0000 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit On 1/10/2018 5:52 PM, Ard Biesheuvel wrote: > On 10 January 2018 at 09:43, Udit Kumar wrote: >> Hi Ruiyu, >> >>> -----Original Message----- >>>> >>>> And this change will not impact any other hardware so no one is basically >>> impacted by this change. >>> >>> Your buggy HW only need the value zero. But the addition of PCD exposes >>> an interface that can use any size of PRD. >>> I am not sure the AtaAtapiPassThru can work if some platform sets the PCD >>> value to others than 0 or 3F_FFFFh. >> >> I don't see someone using this driver will set Pcd randomly, but I agree on this >> point other value should be handled. >> Error or Assert could be added, if Pcd value is not 0 or 3F_FFFFh. >> >>> Can you please >>> just duplicate the AtaAtapiPassThru in your platform? >>> Because the driver is very stable today, not much code sync effort will be >>> needed if core version is changed. >> >> Duplicating is always a possibility :), but When we will push this duplicated driver >> (just for one line change) for upstreaming. >> will this be acceptable ?? > > My main concern with this (and with using a PCD) is that the setting > affects all SATA controllers in the system, including ones the you > stick into a PCIe slot. > > So I think forking the driver is the only possible solution, but it > will not be a one-line change: you need to ensure that you apply the > workaround only to the SATA controllers in the SoC. > Depending on the new driver's location. The package owner decides whether forking is acceptable :) -- Thanks, Ray