From mboxrd@z Thu Jan 1 00:00:00 1970 From: David Daney Subject: Re: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536 Date: Tue, 16 Feb 2016 11:38:59 -0800 Message-ID: <56C37AD3.4030407@caviumnetworks.com> References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com> <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com> <20160215183041.GH3965@htj.duckdns.org> <20160216144250.GD31343@rric.localdomain> <56C37524.5090000@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <56C37524.5090000@caviumnetworks.com> Sender: linux-kernel-owner@vger.kernel.org To: Tirumalesh Chalamarla Cc: Robert Richter , Tejun Heo , linux-ide@vger.kernel.org, stripathi@apm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org List-Id: linux-ide@vger.kernel.org On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote: > > > On 02/16/2016 06:42 AM, Robert Richter wrote: >> On 15.02.16 13:30:41, Tejun Heo wrote: >>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote: >>>> There is no need for special Driver, AHCI is sufficient for >>>> ThunderX, the >>>> file only contains this interrupt handler, >>>> is it preferable if this interrupt handler in libahci.c with others, >>>> instead >>>> of separate file? >>> >>> Yeap, just fold it in ahci.c with surrounding #ifdef guard. >> >> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a >> kconfig entry for this to arch/arm64/Kconfig. >> > Are you sure, this is not a workaround that is based on alternative > framework rather on pci device and vendor > > do you think CONFIG_ARCH_THUNDER a good alternative? No. CONFIG_ARCH_THUNDER should be removed all together. Grouping a bunch of unrelated features under a single config variable creates a very brittle system. What are you going to do when a new hardware revision is released? Create CONFIG_ARCH_THUNDER2? Which one of these two would you select if building a kernel? It is a choice that we don't want to force users (kernel builders) to have to waste mental energy on. Instead, let's try to make things work out of the box without having to set a bunch of random config variables. If a generic arm64 kernel won't get too bloated, I would suggest just enabling the compilation of the code unconditionally (at least for arm64). The use of the code would still be gated by the PCI version probe that is part of the patch. David Daney From mboxrd@z Thu Jan 1 00:00:00 1970 From: ddaney@caviumnetworks.com (David Daney) Date: Tue, 16 Feb 2016 11:38:59 -0800 Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536 In-Reply-To: <56C37524.5090000@caviumnetworks.com> References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com> <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com> <20160215183041.GH3965@htj.duckdns.org> <20160216144250.GD31343@rric.localdomain> <56C37524.5090000@caviumnetworks.com> Message-ID: <56C37AD3.4030407@caviumnetworks.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote: > > > On 02/16/2016 06:42 AM, Robert Richter wrote: >> On 15.02.16 13:30:41, Tejun Heo wrote: >>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote: >>>> There is no need for special Driver, AHCI is sufficient for >>>> ThunderX, the >>>> file only contains this interrupt handler, >>>> is it preferable if this interrupt handler in libahci.c with others, >>>> instead >>>> of separate file? >>> >>> Yeap, just fold it in ahci.c with surrounding #ifdef guard. >> >> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a >> kconfig entry for this to arch/arm64/Kconfig. >> > Are you sure, this is not a workaround that is based on alternative > framework rather on pci device and vendor > > do you think CONFIG_ARCH_THUNDER a good alternative? No. CONFIG_ARCH_THUNDER should be removed all together. Grouping a bunch of unrelated features under a single config variable creates a very brittle system. What are you going to do when a new hardware revision is released? Create CONFIG_ARCH_THUNDER2? Which one of these two would you select if building a kernel? It is a choice that we don't want to force users (kernel builders) to have to waste mental energy on. Instead, let's try to make things work out of the box without having to set a bunch of random config variables. If a generic arm64 kernel won't get too bloated, I would suggest just enabling the compilation of the code unconditionally (at least for arm64). The use of the code would still be gated by the PCI version probe that is part of the patch. David Daney From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755939AbcBPTjI (ORCPT ); Tue, 16 Feb 2016 14:39:08 -0500 Received: from mail-bn1bon0089.outbound.protection.outlook.com ([157.56.111.89]:42023 "EHLO na01-bn1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755854AbcBPTjG (ORCPT ); Tue, 16 Feb 2016 14:39:06 -0500 Authentication-Results: caviumnetworks.com; dkim=none (message not signed) header.d=none;caviumnetworks.com; dmarc=none action=none header.from=caviumnetworks.com; Message-ID: <56C37AD3.4030407@caviumnetworks.com> Date: Tue, 16 Feb 2016 11:38:59 -0800 From: David Daney User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Tirumalesh Chalamarla CC: Robert Richter , Tejun Heo , , , , Subject: Re: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536 References: <1455319230-30201-1-git-send-email-tchalamarla@caviumnetworks.com> <20160214170152.GC3965@htj.duckdns.org> <56C147B2.9010303@caviumnetworks.com> <20160215183041.GH3965@htj.duckdns.org> <20160216144250.GD31343@rric.localdomain> <56C37524.5090000@caviumnetworks.com> In-Reply-To: <56C37524.5090000@caviumnetworks.com> Content-Type: text/plain; charset="ISO-8859-1"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [64.2.3.194] X-ClientProxiedBy: SN2PR07CA011.namprd07.prod.outlook.com (10.255.174.28) To CY1PR07MB2135.namprd07.prod.outlook.com (25.164.112.13) X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;2:y8cCJHwPx+HmxmSONXP0lXwpbdota+TisKxiSlPAg3udtZ1SMKs+yYheh3W2wPrVRb3ok7WnIRpP1FoysFZoDbo27OPd9d0jQ1ftHNHXUbDlfgP4jRxErfXDjbb8CIxHCpJaDTNPKOyB8xb244iXUQ==;3:8Du4jb2gnPs8D3ptglgwCorTEaRrsy6p7+GZkXypz60Evi5Ec92w3fnHviLtYAvUgApjOT2gk7yoZz7LRjN+Q0xz5ltB7HjYTH30Ru360x2pg6uuOj6UqSBbmPLQZn3e;25:p6aN/JwMCiC5sek3Q4/FRW6MIbhv4bijbA+DsVsgXSBRZN5XEvWhCsgEYhGrPbf6m/6DajNlbp0Z/ikn7HLPo/EgCoBSeO1Aij0goXN1BLOgcNXcYtuF7jAGX9JFcK/+QsdwfyCFYOq/0bUHsiz+TIRqET6VUABRSLN7zm9Fg+8alXGH1eUVZ58zP6vcPtZTnUWbSuYNfmyyCOctW9n/viXMb1NjVdlp7GUxYGLlsQIaPGn+XUsC8/kxjsDGLrweo0x8HiKiBxG6kPuS0pISm/Ni6VAxokMQ4WG67N0uk0zxxkdhLZWzv5wzM9vxG2vX X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2135; X-MS-Office365-Filtering-Correlation-Id: fd23e922-0fbd-4c73-e972-08d33708d3b8 X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;20:HgTHaTpBZIuYoIH9PZ4WY0fPnaxm0A3P47lXWuXM/aj8V+TZ4isPOeqwLVzpdhrK90+J8i4C8SPTFl6E8tXodaGpDMmEGbL5AopeVX/YR+9JOyrkJRMH/KFphGtDO5bdKtwnEEOYcgJ1yAoxQCVvtW+pHdRvYGyCjxxVa+gKzQJLDoIoQRkK4Ux4kSGhkUgmJwXfiPILKniNAz9tJe7wNOkzFQoG2N+b+8vV12XXoTnu3Cb7VN3TFGBzH5TAfLnNYH88naGGyBdHb8rrCfGLu7tjziMVCD1iRVe5D3lVCaaWyN8bokzJnwYHv45haHTEvLSPHBbp1rvVW9MB37HT+lsQg7E/WwfQmJVH83FszmU3+TZAXy79ecCplCv7s2ZNrx4VTzpjHBYTexkehTnOB0g3WzzzBVqjTZ49TtjhmsN9yVC5tghSQBO1FH626dEIpo11oSe8ojmY6SwnFNFkkuEh7Wx3ACy5h4dS+rL7fil8fQLdrCBK5Rk2mcYTTqRXqCn2jkZNhmZUsdRdQI+HL0j9CcLytioXqpDCfQ3Lk+H44C9NaEZ+9YbIgXyiaCrZqTFtZ+a3z7szPxlc4rdqPC/tbV1aVyFJ18R0emoQkvM= X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001);SRVR:CY1PR07MB2135;BCL:0;PCL:0;RULEID:;SRVR:CY1PR07MB2135; X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;4:1j+Ydg6RfO/VwtvNIKSSULPCrLrPEgyyL09IhdAKI+YNL4cc0V0a26BtjpHx49VRapWt/7NG6uKPugP+O+u4IWXy1sZqiW48zQERAhHZxsVRaJVd0iNkSUFmzsMRSX46UzePeiPZju7qpHqa1pRpD0KIpT1T2ZKpV9RboL6+XNGADA4y86EQFfzVNJURJI1hPMEPU9d7Y8S8IUUTUGstM7ux6j7HxXDKSSvzntMxSutpGbBg9V/Nm/w9pPCqyYoKElkerTaimRvc7CUd8wNiwZrk4+Iw4NRBrCdtsVxan+MvWVDGBWyqNMWIe66buCbqs4PbR5JtOiT5XzO1imJ7J8Dj13KaKaqx3UoosGrZcsMLplqQm5/hGgHmoLap5i/K X-Forefront-PRVS: 0854128AF0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6009001)(24454002)(479174004)(377454003)(80316001)(47776003)(50466002)(2950100001)(586003)(42186005)(53416004)(77096005)(230700001)(87976001)(1096002)(189998001)(110136002)(3846002)(83506001)(5001960100002)(92566002)(6116002)(4001350100001)(23756003)(50986999)(4001450100002)(65816999)(36756003)(66066001)(65956001)(54356999)(76176999)(87266999)(65806001)(4326007)(5004730100002)(93886004)(40100003)(59896002)(122386002)(5008740100001)(2906002)(33656002);DIR:OUT;SFP:1101;SCL:1;SRVR:CY1PR07MB2135;H:dl.caveonetworks.com;FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?iso-8859-1?Q?1;CY1PR07MB2135;23:GzHAn3o4qcN0MIBwbElh1eWQGK8x2PndR9tv1jU?= =?iso-8859-1?Q?QPa4TyPTtqzvIcI0OJpusirDxQK+DQIZD6SBp8kJ/tMJ8bM6iXe5rn4uO3?= =?iso-8859-1?Q?ZOjDd1/BCGqC12xg1kffH08N2FR/vyK86Dbt9aVbJHEk2xH4BpDiRuQuLX?= =?iso-8859-1?Q?espZ+640AUbtRz9hazQA1HlM2zyQSHwY0pQk0lv+xM5OGP6qn0scLie+zB?= =?iso-8859-1?Q?S+utOi6+5QS1z2DnTZ3Pvt4KTMPKddXrKFb7RrkcP7y3l9oA3sN1CDO1jY?= =?iso-8859-1?Q?jydnFwJi4NrjFWWj3R0XblnCJ/G4omCDI4aoQuky70BQsWiOTh9974Gz6n?= =?iso-8859-1?Q?yYvbj1zgWizzfKrUobE1IvU0q5n97S3GUZRa/qYwfcIogJ4aoWe7cpNtYd?= =?iso-8859-1?Q?LJWR+aJsb83qHig0jiAhV/abnW+XaFd5oC0C9kuEwjFJ5lBDKHrxj7CWup?= =?iso-8859-1?Q?BGyP40RhbQwJrxClicR4hQJgSOzPB+eKMqOJ8Hsk4b+ZMYAgPF8MRBLQTa?= =?iso-8859-1?Q?4ACcUiYw6TyayoJPsBR6cBemcpfQXu1iTm7cI90+il58fahjoQI/Hw3DNL?= =?iso-8859-1?Q?l7t2PjXWilk/tIGMdQxDyLxrP6u0gCVSJZqadBgEvccAv25Gd4JNAwNutP?= =?iso-8859-1?Q?A/2N8RVS5ZkkFbuXlu/NqAX5Tdh9+fU3cj1seiwlcWRmbDgfvcph1OS9lY?= =?iso-8859-1?Q?uCHy9Alk/X3++JwA6e5QcqA+IcrR6kToOuDejNhDGsE9oFiHryXeuLbmTg?= =?iso-8859-1?Q?D4pwHljrUf9lQvqyIU0Ed6tlvze3gB8CQPwSDXoZ/FfcIdoty44CqsQ+pz?= =?iso-8859-1?Q?xYn6eDLZ2hJwvZvW1ywcXS4vdmA061CCcUveV29EWkGEGHKEIdZbExumga?= =?iso-8859-1?Q?ho4skT/+BzJx5PyQzysZ4r/xM5KiWbZQMNwI40r2ueM4w4Q2BDrCWzUuTx?= =?iso-8859-1?Q?0ENLa5q/mvTLcNjZ4oyZQWSnsryYTLvRpPXS5HtSZmxLgRfTDujhIgUbxr?= =?iso-8859-1?Q?nnbOd9VPCynGF/6o5gAvUtOWFjyUb3dA233xwJEtZLx8m4UEYRPo07Pfba?= =?iso-8859-1?Q?qgLrmXfHarWVrywDzQgiVR2g0D2b1eL1LuZnC9y0Y6Vg5HntmBGhYNqaEH?= =?iso-8859-1?Q?OWaLo1wMfP/GPJl1Px5gp3m184m963gf+MwQlJQX2KrlnJgI0f9wupZ5zk?= =?iso-8859-1?Q?b3p7wQUQJiaxl5Nle76BXN5qWfdJ2FGhA=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;CY1PR07MB2135;5:l9ac2CaZ8SURdMHWtNcsn2xMO8PkZCGKbwTJAKop8vkHYaA4tHcGTFBOrxkvFpA9cDZxzo7jTyw6UQo6pvQchLRjzYgQ/qp9GvCW+4uGb2E3Y42Wi1VJIOfBQZ37dTbKR6yepRCXxyPu7E66+kw8DQ==;24:cIy+3NwO8qWXfo2lSeOl+qim9cDb6wF9me/qxNId0fSj1UEXLiPacUoR7IqKOh5PojYKkEVE72a1HzslxQVdyYvFt9/cTZKy9BCECq/eg4k= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2016 19:39:03.3092 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: CY1PR07MB2135 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/16/2016 11:14 AM, Tirumalesh Chalamarla wrote: > > > On 02/16/2016 06:42 AM, Robert Richter wrote: >> On 15.02.16 13:30:41, Tejun Heo wrote: >>> On Sun, Feb 14, 2016 at 07:36:18PM -0800, Tirumalesh Chalamarla wrote: >>>> There is no need for special Driver, AHCI is sufficient for >>>> ThunderX, the >>>> file only contains this interrupt handler, >>>> is it preferable if this interrupt handler in libahci.c with others, >>>> instead >>>> of separate file? >>> >>> Yeap, just fold it in ahci.c with surrounding #ifdef guard. >> >> Yes, please use #ifdef CONFIG_CAVIUM_ERRATUM_22536 ... and add a >> kconfig entry for this to arch/arm64/Kconfig. >> > Are you sure, this is not a workaround that is based on alternative > framework rather on pci device and vendor > > do you think CONFIG_ARCH_THUNDER a good alternative? No. CONFIG_ARCH_THUNDER should be removed all together. Grouping a bunch of unrelated features under a single config variable creates a very brittle system. What are you going to do when a new hardware revision is released? Create CONFIG_ARCH_THUNDER2? Which one of these two would you select if building a kernel? It is a choice that we don't want to force users (kernel builders) to have to waste mental energy on. Instead, let's try to make things work out of the box without having to set a bunch of random config variables. If a generic arm64 kernel won't get too bloated, I would suggest just enabling the compilation of the code unconditionally (at least for arm64). The use of the code would still be gated by the PCI version probe that is part of the patch. David Daney