From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tirumalesh Chalamarla Subject: Re: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536 Date: Tue, 16 Feb 2016 11:50:44 -0800 Message-ID: <56C37D94.8080403@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> <56C37AD3.4030407@caviumnetworks.com> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit Return-path: Received: from mail-bl2on0074.outbound.protection.outlook.com ([65.55.169.74]:42104 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751872AbcBPTux (ORCPT ); Tue, 16 Feb 2016 14:50:53 -0500 In-Reply-To: <56C37AD3.4030407@caviumnetworks.com> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: David Daney Cc: Robert Richter , Tejun Heo , linux-ide@vger.kernel.org, stripathi@apm.com, linux-kernel@vger.kernel.org, linux-arm-kernel@lists.infradead.org On 02/16/2016 11:38 AM, David Daney wrote: > 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. > exactly, that is my initial choice with v1, and only depends on vendor and device id. but it seems a config is needed. how about ARCH_ARM64 then? Thanks, Tirumalesh. > David Daney > From mboxrd@z Thu Jan 1 00:00:00 1970 From: tchalamarla@caviumnetworks.com (Tirumalesh Chalamarla) Date: Tue, 16 Feb 2016 11:50:44 -0800 Subject: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536 In-Reply-To: <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> <56C37AD3.4030407@caviumnetworks.com> Message-ID: <56C37D94.8080403@caviumnetworks.com> To: linux-arm-kernel@lists.infradead.org List-Id: linux-arm-kernel.lists.infradead.org On 02/16/2016 11:38 AM, David Daney wrote: > 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. > exactly, that is my initial choice with v1, and only depends on vendor and device id. but it seems a config is needed. how about ARCH_ARM64 then? Thanks, Tirumalesh. > 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 S1753720AbcBPTu4 (ORCPT ); Tue, 16 Feb 2016 14:50:56 -0500 Received: from mail-bl2on0074.outbound.protection.outlook.com ([65.55.169.74]:42104 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1751872AbcBPTux (ORCPT ); Tue, 16 Feb 2016 14:50:53 -0500 Authentication-Results: lists.infradead.org; dkim=none (message not signed) header.d=none;lists.infradead.org; dmarc=none action=none header.from=caviumnetworks.com; Subject: Re: [PATCH V2] AHCI: Workaround for ThunderX Errata#22536 To: David Daney 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> <56C37AD3.4030407@caviumnetworks.com> CC: Robert Richter , Tejun Heo , , , , From: Tirumalesh Chalamarla Message-ID: <56C37D94.8080403@caviumnetworks.com> Date: Tue, 16 Feb 2016 11:50:44 -0800 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <56C37AD3.4030407@caviumnetworks.com> Content-Type: text/plain; charset="windows-1252"; format=flowed Content-Transfer-Encoding: 7bit X-Originating-IP: [64.2.3.194] X-ClientProxiedBy: BY1PR15CA0012.namprd15.prod.outlook.com (25.162.17.150) To SN1PR0701MB1792.namprd07.prod.outlook.com (25.162.100.146) X-Microsoft-Exchange-Diagnostics: 1;SN1PR0701MB1792;2:Xew/zOmfdfNW/jmMZBNTLsEA8YOiP+4HgQv2gDgG7HQa0XhdzMrGIc35MITjSo7EXT4sCT6aVGZb29UBucvmzJ6uMEX/69/+PQC3SwM5Ud99lpqpQiAJrjR6WRUXUXmh7u7G5kPtqYf24as9pOlo/w==;3:bAzcvC0qzcIJ/rrDu6L5V3oX4Z5sZS4uZY7WLcYLTiM7kjzaY8hEEd9keAKf2rH5fcElRBFjkJLJuxXh6bOvBeqq8T3DfhUd41LCIU5NK/7P7XpG8q5ZIxeLpL+bkR0h;25:C0q+YVkaxsOwacAgNIW/0cXFgZqOmileaKPvdtWe5HtC04cqcx+rNccm2gya7UZSS9XvJUiQVPFtwClzKuNqP1tmo/hQLQQzrMyOQF361AXba9cdoNk276wvsGDQcre+53nLzLl/QQxhMl2I3Uo4tjBL9VSFhmebj7+3+MT6jhdXd9T9jj3fAZZq9fXQjc3HFmlTREZNAtmHa6jkEqjcwSAbwsXERHZVgJocaX//YUYjUeDYvb/FJWIyx1DcWfF8e5T4IIFSUHw315QGb9tE+NQIWYlkcmN2KWSy0ZRTuUVp0FZ9p8FfCewnBscJL6nN X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0701MB1792; X-MS-Office365-Filtering-Correlation-Id: 1bc5ea2d-b650-482e-7930-08d3370a77b2 X-Microsoft-Exchange-Diagnostics: 1;SN1PR0701MB1792;20:kLIrU1R7Y+9o/bEWbs/9hIlPOa3dQVSUdXHp7rIG2KPaycLnKtHUToh6QH9o+5G2b0Un+1AULF0+6jlmv2HTKicJKGMlO9uqzNqiHQIPA/QkCwpIrtH+ML13Qad6UWDcVr9JB0JURdVoBoNaQaSy0/iIb8DCW6Th2MwlzuYzkOLhu4YNBlj8HSw7aa0K1c3HCVCDdyAXMRPbrT4ZHKfjSaAEP7H/bgyAWgAK0oeSMzWssEDhuRbgedGawF5YN5IjXPEks4Dp+/m196bn6iWXFvCWG3v3StGfNqCjLKqJglUgNcSeE6eqoCDu/SUI4otoD5fcv6t9KbBu1PcsSm4NzAz6jhF5gGD47pLhwHAJ25elcJ/YLwSFq25/wICy9uoq7Wm4iHi3Wh2AJ76lnecyuYFUUwv5WkeYgpNGP56YIGwqFuPq7nQWVicTXD/yygh/kuEhjh1/IhFQUgR7wj/sB/+FV34nfcDo5F8OEpDoI0uOXC8X76+PLnl2zjc58lZPAbXchkIn/WMELXDbmHN6QT11QFeFqu6K76Ki2CsG7Dwr8OGhA83fg5dyUjUt56GPbqXfp+DDZBf100BqIum/XUSZTTIv+9ywboXdGlMjlzk= 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:SN1PR0701MB1792;BCL:0;PCL:0;RULEID:;SRVR:SN1PR0701MB1792; X-Microsoft-Exchange-Diagnostics: 1;SN1PR0701MB1792;4:jDXLvCCWKhIHNG59exXZrzdXwPYXJ07LfqekWinceJg13qIalYe55XfHRAoyMSdMuxX+h8fT041pABSOoOr8hAa8LSmZh0sY+duZ2tgNR/iSRMzmVYfr1NWwdm0IfKMhqZhgCdQWBGNT8bDfY5ZoTm6puX4mfPHLFpWm/vljX0/tkNa+MQDYSdMn1UtrwXn+kV9Z6FhdP4rjagqGe7j45abKjn6BlEFOF7bDS+ngaPM63FU4ez3l6RWkg4Lk2XA2W9XHWlotGNXoUwRFQv3RlkoPrY/S0KI5pDA8UjU/GNvYsb3tiCUHSf75WCBwE4/k5yRH+dZdkX9yI+woKAAURb/g4Yw9Gd/0U23jbeLh8kWnw9Qr3H2qwLNFv45QhEAk X-Forefront-PRVS: 0854128AF0 X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10009020)(4630300001)(6049001)(6009001)(377454003)(24454002)(479174004)(164054003)(122386002)(47776003)(59896002)(77096005)(83506001)(92566002)(36756003)(50466002)(40100003)(2950100001)(5004730100002)(65956001)(4001450100002)(42186005)(65806001)(33656002)(66066001)(80316001)(2906002)(4001350100001)(4326007)(189998001)(5008740100001)(87976001)(93886004)(5001960100002)(110136002)(586003)(230700001)(3846002)(6116002)(50986999)(54356999)(65816999)(1096002)(76176999)(87266999);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR0701MB1792;H:[10.18.104.43];FPR:;SPF:None;MLV:sfv;LANG:en; X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;SN1PR0701MB1792;23:0wVpY3qzN+xHEA0y7ix1BnGEoxUXSYLeZYC?= =?Windows-1252?Q?VGLZg9SWv5Zh1u9tWP3Yq9JeDWjRTk2/zE3RL3cPHIsYujHqBYPn9NFY?= =?Windows-1252?Q?VqZv4O1zVtlyjfo7O4iCqcRYpNea3ZWI7D4GfW3z5KV8cUTzGrRvVkYa?= =?Windows-1252?Q?s/flJRmxem/qV10490g2SwFq2/5sZaZCg3nCFBKxRhFNkUeelERyDh1p?= =?Windows-1252?Q?OMEhGREQXkGp76HgStQt+0RGqMeS2RnDdgaqbXHL5ejKPEeI6csWqCnv?= =?Windows-1252?Q?2FtAgIhwR1gtPbVvRX8Q2tdTW14GoexypKYpS6Jo/Bw8m5bR34uaLtdb?= =?Windows-1252?Q?DTMFoyPXmp1TRYpD5pES34U/ieATW5n0bWjvmhakJ10Wajfg32S49Ptr?= =?Windows-1252?Q?jvxXSH+AA0hsH0ROHwub6ERWOzFYn9KkCJFC23fuIdajO69zlSS+eDuL?= =?Windows-1252?Q?T+Htx7ytBKDlkoQY9BhuLqRdIZkjG0uqHFoKcL+/f75b31cnbvDhk1Vx?= =?Windows-1252?Q?oARVsnrY5+prtpYaA5O11NyyJidIuyBGWlpoYOyAUjOHqMus2fdj8kaG?= =?Windows-1252?Q?DVC+Z5CeBWp2qA6kZNXqF40wGxTFZwLOkM9/nRjI9tB5ZY+1O/nhepay?= =?Windows-1252?Q?71ouAvFIEO7v3UlhjHX9cOIAPjBXhotLKUPC2B5Qsx/Kq0rskK8wHOTI?= =?Windows-1252?Q?ljtgH9LmZnVSEGvprzw1NESZKF1AjIXcDaquKeO6Yqvwlq5EtJ0wR3nE?= =?Windows-1252?Q?JFa1Qn3/WkQYOcx4i3YZCLHC37LU/SW/3zYFiiKtINf3dFHmlwM1D/Ly?= =?Windows-1252?Q?xmnvtYQdlnyyRkCTWuqxdEoTsSsrekiBCxKiJu2U8fzmRChIsYBC9PZo?= =?Windows-1252?Q?KI2Y84KkowZhx5y12XeqM5YEN646injoykafdKsDwG1KMB2CeQf8PDjE?= =?Windows-1252?Q?1H3F3h1CBPWZ7P3USPNnO0UfAEeYpg1vxwwimKdT8HvGWoh3nz0km1EK?= =?Windows-1252?Q?EKjjQkJAwYSp9tcKsKKCV4+afY4oYgI6VMfhVE5ei9bOa5TwUba3nWID?= =?Windows-1252?Q?UlGV1p1xCqiBr5QnMC+DW+vpVSqIkaKn4aKqj/xSuP2IFLfSbDJQtHwH?= =?Windows-1252?Q?lW1NzUjHyFRl/4uooxUj+MJsAfFS72X6rFIenuYgX7TGkj1Vbj/YMxeH?= =?Windows-1252?Q?rvACgxnK+ARFUsyXhoH4rMIoPLPwasHOprUplnDxiMh52CeHF1eWqgqo?= =?Windows-1252?Q?CSlOdA2mkCpSHthK9zg=3D=3D?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR0701MB1792;5:WY62/aoIh+7inuECQjONqeXkaDGLrFijE5z5hFKoHfS9W/B97hOvlQKvzbU5LKs9aRFEcFsLKvF20DDjWIJoWh9n2GLW7uMebIUAwyQXeqEMf+8TlDTablJT2K23AtbHzrEyvnJYo3VA+2NM33KSxw==;24:o55R2m84vs7cLgc4ylXkUp8w+BwB+U7g2br1bnFTsWCsxWW2x6E6OPh1QQa9u31XdH7pRTlG01VaT5Ya8MAdBUxVOJFyhPYt1QS6nYKeJNE= SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: caviumnetworks.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 16 Feb 2016 19:50:48.3163 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR0701MB1792 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/16/2016 11:38 AM, David Daney wrote: > 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. > exactly, that is my initial choice with v1, and only depends on vendor and device id. but it seems a config is needed. how about ARCH_ARM64 then? Thanks, Tirumalesh. > David Daney >