From mboxrd@z Thu Jan 1 00:00:00 1970 From: Brijesh Singh Subject: Re: [PATCH v2] ata: add AMD Seattle platform driver Date: Tue, 26 Jan 2016 10:56:20 -0600 Message-ID: <56A7A534.6040208@amd.com> References: <1452789071-4090-1-git-send-email-brijesh.singh@amd.com> <20160125204300.GM3628@mtj.duckdns.org> <5730117.gx9ezcyLp7@wuerfel> Mime-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-bl2on0079.outbound.protection.outlook.com ([65.55.169.79]:36944 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933988AbcAZQ6t (ORCPT ); Tue, 26 Jan 2016 11:58:49 -0500 In-Reply-To: <5730117.gx9ezcyLp7@wuerfel> Sender: linux-ide-owner@vger.kernel.org List-Id: linux-ide@vger.kernel.org To: Arnd Bergmann , Tejun Heo Cc: brijesh.singh@amd.com, linux-kernel@vger.kernel.org, hdegoede@redhat.com, linux-ide@vger.kernel.org Hi Arnd, On 01/26/2016 06:17 AM, Arnd Bergmann wrote: > > 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. > I am not sure if we should label this driver as a hack to workaround the broken BIOS. Unfortunately SoC did not implemented the enclosure management per spec. Its not BIOS issue. > 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 did looked at your recommendation for extending libahci to use ledtrig_ide_activity() but as I pointed out in previous discussion this function is missing several key features from EM (enclosure management) pov. e.g missing the slot number, missing the locate and fault led. In case of EM, each port will have at least three leds (activity, locate and fault). Since these LED's are part of EM hence we need to ensure that tools like ledmon and ledctl (which uses libahci sysfs) works well. The main question is, what is recommended approach to override libachi enclosure managements transfer led messages function? A platform driver or something else. Tejun and/or Hans do you have any recommendation ? - Brijesh From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S966881AbcAZQ6y (ORCPT ); Tue, 26 Jan 2016 11:58:54 -0500 Received: from mail-bl2on0079.outbound.protection.outlook.com ([65.55.169.79]:36944 "EHLO na01-bl2-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S933988AbcAZQ6t (ORCPT ); Tue, 26 Jan 2016 11:58:49 -0500 Authentication-Results: spf=none (sender IP is 165.204.84.222) smtp.mailfrom=amd.com; arndb.de; dkim=none (message not signed) header.d=none;arndb.de; dmarc=permerror action=none header.from=amd.com; X-WSS-ID: 0O1KKHS-08-D18-02 X-M-MSG: Subject: Re: [PATCH v2] ata: add AMD Seattle platform driver To: Arnd Bergmann , Tejun Heo References: <1452789071-4090-1-git-send-email-brijesh.singh@amd.com> <20160125204300.GM3628@mtj.duckdns.org> <5730117.gx9ezcyLp7@wuerfel> CC: , , , From: Brijesh Singh Message-ID: <56A7A534.6040208@amd.com> Date: Tue, 26 Jan 2016 10:56:20 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.2.0 MIME-Version: 1.0 In-Reply-To: <5730117.gx9ezcyLp7@wuerfel> Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: 7bit X-Originating-IP: [10.180.168.240] X-EOPAttributedMessage: 0 X-Forefront-Antispam-Report: CIP:165.204.84.222;CTRY:US;IPV:NLI;EFV:NLI;SFV:NSPM;SFS:(10009020)(6009001)(2980300002)(428002)(189002)(377454003)(24454002)(54534003)(199003)(479174004)(80316001)(4326007)(2906002)(50466002)(87936001)(83506001)(92566002)(86362001)(23746002)(59896002)(36756003)(5004730100002)(64126003)(1096002)(77096005)(1220700001)(230700001)(54356999)(87266999)(2950100001)(3846002)(106466001)(33656002)(4001350100001)(97736004)(6116002)(5001770100001)(65806001)(189998001)(5008740100001)(76176999)(50986999)(105586002)(65816999)(586003)(101416001)(65956001)(47776003);DIR:OUT;SFP:1101;SCL:1;SRVR:SN1PR12MB0861;H:atltwp02.amd.com;FPR:;SPF:None;PTR:InfoDomainNonexistent;MX:1;A:1;LANG:en; X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0861;2:yih7i6FblALe9u8xHDFXo9qbLr9ueX43WCAr2VlbDzrzo5qnRJ7ecLio/t6QpFEBHPZkvT1+MQBZ6Kwvil74vn74VJDEYPnzNJM+dDHZNCXicPUw9OqYj3gPQZ68h0fPXUjgSFiPfK3oiaQP92I7QA==;3:jO+1Ulfm1a1QBIfUdJalVQuW6zUh9oMeQvdk/JTK/cqxnpI121eHH6YS4l8fMTc1WUbpOXXkG9g/TDlUJP078zphqiyBzLoUraZEhyQFfQckPa6+3zpSu2en+jUy3nfPwhEA6Y8xcM9pNA4tligybzIi3WUn6UiIdABjkedv1344HFfN7RD17a8FHMrI06sLQmTuO6xnLmR7OGXf/3eqtNvnqlsB5lipwPxLJp28hrI=;25:cFu03YqMzKLWWgIPcRFxQc6nSj+7X66WtxKXVC+Q6GaoClMiFfJp4qWyMx+H+UdDcruhHKOKRINL3+CGpIlpUx0xMICTC8w63xGrrhOf+zHXnhBxIJg4Nwfgp+R5IBX2+UkS5+tKKAP5ifsnFnGSehvvChjHN94AxwTnhzhXIKNXzRI5FC0sqV6eJyFdfFEdLURutz1cCo2CGnj1DHsHKl4pE6jKv8j7uVuUNVBYo2iNzQ1MIjv7twqRZtXUNnD0 X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:;SRVR:SN1PR12MB0861; X-MS-Office365-Filtering-Correlation-Id: 36c30e20-9538-4b57-ec6c-08d32671f457 X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0861;20:+hqxNSppaY64x1tnnxdoJzic4swZ9vzbCr/5l9u9x0hARvHv78A4H4LUtyR9Ms5bI7aTtKd2Xm2GLeM2NHjVdkFCIEH6VJU5+LeSkAgziMeuybMRvHHGAxiGd8m91vl/WF1hfJuyXUrl+k9Fo5Q3uSwssIBupajR9Txi80PoihdVNGKLSt6BX5/XBTT4h7uyJ8uCLWNapcyOy6YhcD9nB4OKzvSsi6duNsro8e5ghYm5kOiKe7yrRj4gg5hTLXIGjOS9SE8eQ8wGGm+glRxKlnxT6mmvYZQ/67snEi6rvwByI3OEnrI5JkIBuLwyoO9xl8dMfM+vSi3Z5GYlH2Vl5B4WGk/pCkzWq1rZbKIBkudul2mgiLAysNmC1HYBHk3z/vlnKyodjm957XzDKmtDQH3wQU412589bMcamGBNaRPiwuyON9rE2HlRoNrTkLLgLtnEA7XC9RacfG0MZ0bGFeCmoKt7r8fdSF1kBAqcr3kApckCKyUwT6+4xLuuQ0vB X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(123027)(601004)(2401047)(8121501046)(520078)(13023025)(13018025)(13024025)(13015025)(13017025)(5005006)(3002001)(10201501046);SRVR:SN1PR12MB0861;BCL:0;PCL:0;RULEID:;SRVR:SN1PR12MB0861; X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0861;4:WvrEvXbrTK4Vn3VJ5FuvcC0ooEGMG0Gk2XXWP0jGNGGoS+EXr2XBIP4AD6Uw/unjEnEm2YOFAxj5L61AeloPjIcqmQA1B9mkKzaTLd2NARSOZz6JVceriwLv8TDfsYPzuC4d0xfrf8LiVl9O/50GDJtFOoKbe5siTTOoYstN7zkue5q1NRR3s6WB3q021Mg+xSfVKX5+A7u3+wNDmeePYavV1AN4hdcEbyZwAkaOvijqvd3XepGG7CzgctLwOyiwgCuNxafU35dvkLuWGKa5aYkd2+Cqq/cn0B0aQ+ndjY4jzot3HBMAPQxy4Dh659t+BEBb3LlbV3rynrF1wPnpG+jPAqX4KRXUjzQMpn2L5JMINecvilXHbjpfj5xG5AU9zRmIfrpDqqkELPo1RB49wqXxSkSWJEFYcDgwCK6zANDbcQeEA1yJbJ1QhJlsFsSqUJOBLX5w07oEjBGT5hllw9snz/f1vV80XdrlrX82zn2WQ2iCeslpfutxBTA8Avht X-Forefront-PRVS: 08331F819E X-Microsoft-Exchange-Diagnostics: =?Windows-1252?Q?1;SN1PR12MB0861;23:xH8/UXycVjfS+DjsuKnPfV/lZ8xKSXXEvubRF?= =?Windows-1252?Q?qU5oXZM5eYhkhvb62n/LaXfcOz+32Re2OgKsuRxYeI1sngMECYtDAJqP?= =?Windows-1252?Q?1NlxvasrAVMKctY4Cce/nVDmAzsN6mTTErR3HcDT9qDRMPrL1ReicJ2j?= =?Windows-1252?Q?T9nyPgou1OG7ZT3X+/cFJp1ha4BTPpHhOYQX3iYwMsowmoDNMZrdzR39?= =?Windows-1252?Q?NSAFiCfX3CqMTUyCFthBKpllI2FmBc2oMHM0Jh2unE2VF6PM07p8Iiab?= =?Windows-1252?Q?DaflWU0omn1MpKSSNUHD0yyURkaa7ZuKjeoK1FLNkt+YWpmHo8qPLsrF?= =?Windows-1252?Q?G8iFd96W0//JMoSWbAQg3HVCW3vOhk8FGXgPO6pODf0sxI+PmHbnIBGS?= =?Windows-1252?Q?c5W2TGb0inB+6zhBLsc7d4y6Z5R/8G9Oq54LoO9jMJOKfMK2LHEkON8X?= =?Windows-1252?Q?eabFy0qd57O8AbQ74yB+dw1/mtreeachHEbwl2odvbZpoGjfolrpp7Eh?= =?Windows-1252?Q?YoEfkEgtH4/urqOFr3/LbTemn34KoSmvfh8tqIl4pb8r1wjlBdBCI9+Q?= =?Windows-1252?Q?2g5QeRatgEY5l0Sr6SxaIYDhkPybqchSlYUo3+Ta/VZBfAaJkUwub7y6?= =?Windows-1252?Q?XNsOeLZfqm/+JLU2AdE//cq3PhT44KYe2h+RaTjD2tG4qJ5c5ecpC6+B?= =?Windows-1252?Q?x2YpiJgh5k3+Db73IBe59WDnycsIdGBhtssub0tQqx1vOlhvRs3JU+lb?= =?Windows-1252?Q?ihExu5Xo9cvF8KL8ogtO0Omctoy/OXS6AwEf9xJQKLPC/fg+kKYv4nRC?= =?Windows-1252?Q?Sw5e52kng8hWN5H0LRlBmuduNgqRVAadB64baCWnxOqBdBOhiwbSKZpI?= =?Windows-1252?Q?HaB3Ynl4o76xwn4tmUdvua2PMDlvrgnh92CvkqnkdMG1fxT9TEJC/NWV?= =?Windows-1252?Q?rSIUjYDSi9lwbQkfG/0KtAN6NP6YdKKjzX8o8W2ZkvVMWKT3Rz+AP/3N?= =?Windows-1252?Q?bxISycRr9tgoIegbQZXpIM10Q9brVgwRizFWgj7/8CW/hpGwGFPMzDn+?= =?Windows-1252?Q?gL4AmxP52ovcvx7+OHhmvweKnvCBZdY4ICdbS4MudjW2HNVm2woSUO0u?= =?Windows-1252?Q?46rDJYZdyNB9Khp6+1jXPCJ9yYZjRv4OTCPn8p3p1C4OPxIWLHA6RsLJ?= =?Windows-1252?Q?47HeBS/xRN8iuZr7yw63BKRsHdQyKV+QO1OPsVr0mo4L0l+tY6J2kCPp?= =?Windows-1252?Q?IlxDRkOTh1ZnGZgFW9VnbPSUBBUE19h/Yom51vgDjfaKkGvD/xFu1W+x?= =?Windows-1252?Q?SBf?= X-Microsoft-Exchange-Diagnostics: 1;SN1PR12MB0861;5:PgsjNJ2jg+Oo0CJa82mGOKihRfJoMDDf/mOSioqpiTMGMnQq4MiwKTGUsJwsm101Fl+KdJcf1P2xJ48H84ff9WzVN2aYWUq2baVgt77jBozFoS9YkrUGkNAUdHm/hfzq+NinQgvI08e45bTtpkRzog==;24:6uKZZcYPgVNfv/nT7Kleef2wTsc6hdrj9hvSYdCYxeEwUtuNZL+HFlgOrthG4QMbeHsUrUWv08cOl4bjzFfRVs9IR5EI1USthAODEtDeVcw=;20:OD6a8byHL3Qg9lchjeYKgNsLgeE7+GYakycQ3yj95RiSL2l7YxMwzOfjHk9xTL5/JqUUhlWnC7ZBjmYxYaHaShBKjrad5E7cf3gu4XRhAwnmTFb8CoERlRwqHObmBFqgeIA0jnE806iElSZU5iwES4T3CTZBWR4fibeYTAJufTDIgjzfRInmosiYTgKwhf1u5LuoXaOm1HobhB3FMIWo+ZjXN0TwxZijg7aKdo1tIF6nq09HVTcJtc1RkmgU+afu SpamDiagnosticOutput: 1:23 SpamDiagnosticMetadata: NSPM X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-OriginalArrivalTime: 26 Jan 2016 16:58:45.4590 (UTC) X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-OriginalAttributedTenantConnectingIp: TenantId=3dd8961f-e488-4e60-8e11-a82d994e183d;Ip=[165.204.84.222];Helo=[atltwp02.amd.com] X-MS-Exchange-CrossTenant-FromEntityHeader: HybridOnPrem X-MS-Exchange-Transport-CrossTenantHeadersStamped: SN1PR12MB0861 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi Arnd, On 01/26/2016 06:17 AM, Arnd Bergmann wrote: > > 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. > I am not sure if we should label this driver as a hack to workaround the broken BIOS. Unfortunately SoC did not implemented the enclosure management per spec. Its not BIOS issue. > 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 did looked at your recommendation for extending libahci to use ledtrig_ide_activity() but as I pointed out in previous discussion this function is missing several key features from EM (enclosure management) pov. e.g missing the slot number, missing the locate and fault led. In case of EM, each port will have at least three leds (activity, locate and fault). Since these LED's are part of EM hence we need to ensure that tools like ledmon and ledctl (which uses libahci sysfs) works well. The main question is, what is recommended approach to override libachi enclosure managements transfer led messages function? A platform driver or something else. Tejun and/or Hans do you have any recommendation ? - Brijesh