Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932428AbcKYQUA (ORCPT ); Fri, 25 Nov 2016 11:20:00 -0500 Received: from mail-ve1eur01on0112.outbound.protection.outlook.com ([104.47.1.112]:44933 "EHLO EUR01-VE1-obe.outbound.protection.outlook.com" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S932254AbcKYQTu (ORCPT ); Fri, 25 Nov 2016 11:19:50 -0500 X-Greylist: delayed 87521 seconds by postgrey-1.27 at vger.kernel.org; Fri, 25 Nov 2016 11:19:49 EST Authentication-Results: spf=none (sender IP is ) smtp.mailfrom=peda@axentia.se; Subject: Re: Getting at gpio- and pinctrl-devices as a consumer To: Linus Walleij References: <1479908035-18284-1-git-send-email-peda@axentia.se> <20161124151420.GF4271@katana> <46be889f-a558-0174-f638-c685b23c8ed9@axentia.se> <20161124195230.GA1666@katana> <45787444-a237-7363-5f03-0cd207cb82c2@axentia.se> CC: Alexandre Courbot , Wolfram Sang , "linux-kernel@vger.kernel.org" , Peter Korsgaard , Wolfram Sang , "linux-i2c@vger.kernel.org" , "linux-gpio@vger.kernel.org" From: Peter Rosin Organization: Axentia Technologies AB Message-ID: Date: Fri, 25 Nov 2016 17:19:42 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.5.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit X-Originating-IP: [217.210.101.82] X-ClientProxiedBy: DB5PR08CA0004.eurprd08.prod.outlook.com (10.163.102.142) To AM5PR0201MB2305.eurprd02.prod.outlook.com (10.169.242.149) X-MS-Office365-Filtering-Correlation-Id: 7fa8e27d-cffc-47b4-c4a1-08d4154edfae X-Microsoft-Antispam: UriScan:;BCL:0;PCL:0;RULEID:(22001);SRVR:AM5PR0201MB2305; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0201MB2305;3:w7Ta1KOKRs5SLU15+Dd1jP1FST4cfxrMB4Dd78wjQ/aY+QWuUFCHUG3NwIotnBAJQgXz0LjsqXv3OOtix/TiTwEWVK84pCXwiMfJZYmEA/nvktdVdxyE7CuHwgUwrCtmmAWXXnGmSWnhVzdyYODcgUT/d21lJzkB5wzzuv2TsFpga9XiLqWH5NYUdlk1rBQnl4MZFe/MrP0ZhXnGs2/hBl7i7sM3THGjM7kaqxeyXNvoCOLfy/xnyMsTX3K4sTi8V6OPb1pXZ8hLHYnuBFaUoQ== X-Microsoft-Exchange-Diagnostics: 1;AM5PR0201MB2305;25:DF1minTpbgUDwichMSFfBKZx2QQlnwtgeSP7A+mBmSLSOUm8q/N/Zn5oRJ0jvO3NWxSXBISGA4fmKFG35g2YCM5PCyur0VbniwxPZmfxNqnIa1WX+DKXCPAtuarJEJgok6zDdwY+Eu6lfrr8WyehG3A4jag7OZlxPZcJ4IDa5nT+3DDLIjzfPn0RMn1KOFMFl7Pk/J4qPOkXN/h/2MXNinlYs3D3RrRlh+OkM5BoGhwx9BOf2iJ9neJh0gS1MMiCNsraSv+/gwFGkdN1socFRsaUtDXU4WOWlM4FnN/jQQzR3+e3e4hWfLeFGSRdGwySSXMKQDFbDEJ6vhpGTXy1ydMgqnGH1KURjPxBljlwlzXc0RPtaAQtxROz1GbIrVpglJ1Q4lie79s6/4F1xV1l8SRbZznl6Bn9AJBZiXMh7PaCsnlaoL1RGYPpRM+jcnhphVS6jHDAAaEyQlvc6qTrCRrjW7drT4KPwa36GGpz4ddZXPnC9nJe1srCVGciNEOm6NWe69EhGfJXqrn1TrIwFb/UmaTgrBthPua9leZBNeErQXSCOd6wv9HcatG03lRnCwx/ThLdEPHSaI1sd/Pjp/4CSL9X1ULhwMQLOLDD7xVMaSC1zGNfSBAV9aweKVxwoN99Er/5IqHKY7DPsIU9DYmC91Xl597lZ26Lknga4yej/v7KeAjZWAIWkbGYQCsnUJu5euL+YlfNL96ehTPIDGx2XXwThn/GcybpfdwwPG/JEH7y5Nv6EbWzi4yW+xnq1xq3zFKBKT9Y/udZS+GHUE6MT2H227k4sPLbRa0ycUaVrCRJ6OP3pqCSlRpM+BGNzVirrbrFC2BB5SZgLwA1rvuM3FU6eQg6fr1wu12xPMUvAVO20+BNFmFEMUbwvIer X-Microsoft-Exchange-Diagnostics: 1;AM5PR0201MB2305;31:we0OTl2Cfh/v5rT2B2ZdlLXhxdljNNbLBFyz/WLt3n/fR/cV8AOr+40T4SerG/K3tv4Dah934n/3G8SMOg4ST3twDW8uacKVIv25WlK91wYzAuOb7mDSmWiD0eyyvFjkikB2bKgvaOUqQ3ordqwfEDDMecO7KFKREslZz4K6c3oPiuB338hEA4BbLAvETBN7uQwgOi73KN3b9Tiq9Ixim0LNSN6yet0eysemLYAUnNUlp4dqZkdDnLVR9McRJFsCtsbDeNOD8I23Q7IXwgEvtg== X-Microsoft-Antispam-PRVS: X-Exchange-Antispam-Report-Test: UriScan:; X-Exchange-Antispam-Report-CFA-Test: BCL:0;PCL:0;RULEID:(6060326)(6040361)(6045199)(601004)(2401047)(5005006)(8121501046)(10201501046)(3002001)(6061324)(6041248)(20161123555025)(20161123562025)(20161123564025)(20161123560025)(2016111802025)(20161123558021)(6043046);SRVR:AM5PR0201MB2305;BCL:0;PCL:0;RULEID:;SRVR:AM5PR0201MB2305; X-Microsoft-Exchange-Diagnostics: 1;AM5PR0201MB2305;4:0DKagB5UjuqkfJihxMpl+CyXMBK9hMExpHDpFsNh5Iew539OVBSxv2w7+OGj8VA3dlcDfpNrWeJvExFZRPpZwRFYlS1vsH4MJJifC3ZTLY5IYXV38mUMqnhiinO1Rekq6kkO2ld1RCTHcLL1Ok+Hfxvxpb6m4cB0G0VH4FWsPWi7GWJn6zrPCcf27ycpMsTlj3RORo5hRJDTvlJDc8EAkKTG8kj2GVyYrfoHBOP/jG01/68+B3n//xY3o7F9v6Rab7+91COYV2QmewZs1p7Py8rVWUnUgxdtlNe12rIPCh6z30/5+ROOaq2VrDLWQkwQkBMFCgkWMxXXTx5l/HLASOKlp/bxnWum9L8HLSQwZ3usRWI7zKoL1JY9jG5LIcX1vb355cLfveI0wm8iHJ9aanRtCy+Ye7uxzABvNqV3E3ZSirLjcaWdrxtsB5jD9aWjSXvThhZj+pNoCecJrM2U7dWYzm1Ac1D9M5ORsq/d2Tqr9JRZBB+zlvwFLfe85DIbFD+CGp3hQkjbma7OmrQALFi1GolWx2DXFz6aqllnK0aReGlXXNwYI/tU4XoniXFq/x9WQtyy7fWID/RoHfCc2FHQTMko5WJ+KhClUjgg45gczUsuC9Xjh+JOAEUmJzHwntwEng1HRWQIr+CSaJteWTkyCxZY9OvE4cgetwdDe7x1X/B9JFIQr31BVTgw5E58 X-Forefront-PRVS: 01371B902F X-Forefront-Antispam-Report: SFV:NSPM;SFS:(10019020)(4630300001)(6049001)(6009001)(7916002)(11905935001)(377424004)(377454003)(199003)(24454002)(189002)(8676002)(81156014)(93886004)(81166006)(6116002)(3846002)(117156001)(66066001)(105586002)(68736007)(106356001)(65956001)(47776003)(230700001)(65806001)(31696002)(86362001)(31686004)(74482002)(33646002)(50466002)(23676002)(42186005)(189998001)(229853002)(39400400001)(4326007)(39410400001)(39380400001)(101416001)(38730400001)(39060400001)(4001350100001)(305945005)(4001150100001)(54356999)(64126003)(50986999)(76176999)(92566002)(39450400002)(7736002)(7846002)(97736004)(2950100002)(5660300001)(36756003)(65826007)(6916009)(6666003)(110136003)(83506001)(2906002)(77096006)(42262002);DIR:OUT;SFP:1102;SCL:1;SRVR:AM5PR0201MB2305;H:[192.168.0.125];FPR:;SPF:None;PTR:InfoNoRecords;A:1;MX:1;LANG:en; X-Microsoft-Exchange-Diagnostics: =?utf-8?B?MTtBTTVQUjAyMDFNQjIzMDU7MjM6enc1V1Jkdk9uRzgrdEJkLysyTlA4bWU3?= =?utf-8?B?Tk5WVUN2R0ZSenB0OEdwQ3R4OW1PWXh5bkZ1aWtDRXd5S0NPTXA4NXNFNXRE?= =?utf-8?B?S2F3QlVDeG9TckxhZkZwQVBiTXkzZ080U3lNZklJUVQ2U2U2blkzaXZGOWxj?= =?utf-8?B?QStmN0V4Y1JLOG5JRkF1RzdveXRtS2pSWCtpeUV0MmJ5SU00bXRwa0pic3lR?= =?utf-8?B?YVRaWGVML3pjWHRwTjFXcGxiUkZEWWx4eXVVMURtRENrcmlZc2xaUmk0cU00?= =?utf-8?B?WXZ1d2pGSXFJN2I5STZKRE5KYjFubjNabVJHa2xvUVJnNmRxd3lkR2NrZ0M4?= =?utf-8?B?NlFMUjg2M055bEtkWXovcDBtZ1pjcktyRFBPTnJnS0dOLzR2NEllWmdwekdw?= =?utf-8?B?bEpCbTlJWGs2OGtWS2hnMHBjV0Ivd1VDSEEyM0x3aXd4My9iSVBGRWt5U1Ri?= =?utf-8?B?SDA2citwSkpleTMwV0g1QnlxT2JmMU1aa1ZyUkdtdXpzZmJXc1l0SDAyQ0JU?= =?utf-8?B?QTN6aHlud0E5dzhVMENKQTFUZjNqVjBDWWRnWWhBV214MFA1T3dzUUd0MVl4?= =?utf-8?B?bnh5WkVtdWgxQ3pQQlV0Ukc4MTI5eE9OcklRNGhEbkxMN2l6RllaRmVoRkJI?= =?utf-8?B?ZUhiNjk5UGVNRTQxaS9hbkVZZU9pN3lCa2I5NWg1bjBadDE0UWJuVDdwcm5D?= =?utf-8?B?QzlYOU1weVdlQUpzQXJybEFCS1FzL2RKNzZ5b3E5ZWZZaUd6ZGw2R2VkSFNI?= =?utf-8?B?M2d3SVAzU3krY0ZvYnA5S3o0dHFvK1lEdzBCbmlwaXlHamN4bjJPOVM3TmpX?= =?utf-8?B?T1p6U1pPVWRDR1ZwT3A2MkR4WCswcHAxbU1nMXBrQVViQjI1Wi9Xazk3eG1N?= =?utf-8?B?QTZUYlFqVEQwWms5enN6ZXN6UmhUckVoZFlXWUdYNEFpRXEwNDBpY2cvVS9a?= =?utf-8?B?aE1ZYmpsTWVNZFZOWlhWamM5Zm5KVU4vcUJWQVJEQld4cmNjVnJFNGlDelAr?= =?utf-8?B?SjVaU2dVa0c4c1E1c1dOZkkxeXNhRjVkeTZFSnBvbkY5ZWtJVGNDY04vTDZo?= =?utf-8?B?dnZQVFRFQTNXTmtOOFRxS0JlNitmMWYxZTI2Sy9LbUtnZ3hvRFdMVnNKOHZk?= =?utf-8?B?WGkvUDg3eVhFYmFBRW81R0JKK1pCM3FSeW5ldE4wdVNrOVRYaG1EVUZSREhE?= =?utf-8?B?L1psdkJVKzdPK2NXNUpRWk41SXYzMEdwYkhpM1U3VTRwd0hUd21vZUV6eHJs?= =?utf-8?B?enpELys1eWF0Sm01eERBcnBLL0lxWU5rQkQzSDU5dExQVGgycEdDNklzbE9t?= =?utf-8?B?dGJvcnJNaUNVMkJ2Znc0T2lHeVhMVDJzbDVSYVlhbmJwNEovV2pCMFJLMk92?= =?utf-8?B?ZlczMnNWQmxlK2paZDNod21tbjBJdmw1Q1NSSHF1bGRNbjdPMmJqa2RaQ05O?= =?utf-8?B?TzVOY21CZWdwa0ZoU1JOTVJaQVZqSWNwOTljSXNMakh1YUt4a005eVFjSCts?= =?utf-8?B?OVFWL3JLa1VPaHZsZ3FiZGN2VTFwb3VweVJBV0ZzNFZKSk1CNEJUQ000OHdE?= =?utf-8?B?SUVQN0g3M3VsSFZWQzZRbGdNYlFGd0V6VjVOZHFOY09jcUR2ZWhicnc5SUVO?= =?utf-8?B?eU9EZ05aYURSQWVxR1NpK0F3ZWh3cUoycVBpNG5HaDhQUmc1cElHOHZjSWtC?= =?utf-8?B?Sk1pTHh6VThHRzhiYTJlaWtDaVQ1c1F1dUJHTXFRemtpN1U4cUgxeDdUTml1?= =?utf-8?B?ejF3WEg2akdYUTBsdTlUL1NnMGQzNU9PaGRiUW40RGEya1ZKSW1rLzdJbVYw?= =?utf-8?B?dDcwWHhMY0dqV1FjYW5BQjFYL3RGN2V5VXNDeUVYeUhUY3BHSkpvTnAzUW9u?= =?utf-8?B?M3pIVnV6blFwZUNILysyWjBXMW1YQ0FHUVRXdGRzNWtsNkpPSEdFd3QzaXNx?= =?utf-8?B?cXYzNDhTdVd2QnFtZ3FHejM0NGJBUUtxcUwrcXd5eFJuSGszYXVOcXJiNUtu?= =?utf-8?B?YTdnU29YWmduZGVtZkl0S3dBS0oyWXNnNSsvdnJUR0lHTmltWU4xZnFVL2pk?= =?utf-8?B?ZkhXbUlDMExFWDdvZzN3Wll0OStGdDAwcjhDMmk2M3REQllKZkFDd2NNTGVH?= =?utf-8?Q?AadFC+l48RzNbbe32PNwmvYnU=3D?= X-Microsoft-Exchange-Diagnostics: 1;AM5PR0201MB2305;6:X2jtPc7NFWgSOYJHRDYXFT3pEpaGkOcc6S/Hf9gClkygLDqghN0Qo9vM9PzZsUEIKqj7MkIPxIbuv27oquXmQrtRp6K1DM/koA4RvUfmxTJNLZkv7bVXPMcIKMMEgcWHkWFvZs8S8HDq2zv/NRDc3Fn00u5HHjCEx200DROOdfCUgW585ELEFujNyDTBwn3NTHjd1bdpZ0XC+mMoyHfDzcomY/281aAzYSnWYgCJHAlat8hQodBFWC+tpn5709LvR5dy5H86b0UXCtm6GOY2W9wmLW+HyCGmJdqqIJK/mmYAd4eN6MdhHYmSMgfwuRWp0IsY/P9UmNXM8/cSASwse2+VcUZ/97ASuQlF87eFCkGnCc1mlysEsfFs5BzmplHeaMbZpwN85H1ZUDx2J+RqRoJKKvqSbCjOw0ocPNFWerAxaodgSr8JRo2KHZGElE8SxagJ9T6m0jskHsN7wNhSl8kQlFjKzw2AHi1BbHvjujI=;5:9kAmfHscG3vz04cik+YbT3QklHi7ucNia8eKp2MyXXRshVjCdDICdDJGAwo/qZntsCJz3oXb6VpqhxaM4SCBjdoZI2eRuYA9Mf4X6F3ZjDj5+VgQw5Coqb04GFuk7L+tda1bCw1gaWYWDxLz80kwaQ==;24:lJYGs+5OQxBfusgrCR2HDFANgzKfc6G1IKGhDiw17KR5TUaPIyETEBQG5T/P1XJLb+zShOCmBcpIh+pTXG2kGmzBp917CCB4VSRYSpleqZA= SpamDiagnosticOutput: 1:99 SpamDiagnosticMetadata: NSPM X-Microsoft-Exchange-Diagnostics: 1;AM5PR0201MB2305;7:bCN1CNVE40muG0ChXKUAnEb4NeCagYW73srUcyfvlfON/KEF0VO26VNHMbIak3+7T6n5DLAo0UsqEzlSgP+M0QyPXVgALAk7N6HhLvvtHuQQDH1cbcXjC4YUONOrZlOSbGvgRCM5koevG59Pd4WOItx3Vu+GO2IJR5fRMqkyg0TbQiJ5jZ1RsIBfp92t+XzLTepL0SanWPoEFc+yk2/g1kLUX6IYyFDJeCfGCrR8IyqXi58cbbjEy6CdorbMzMzPwB8ygwW0orRuwJmu1XEJLBclgWIb8PHOGbAI4DBuvDPbQX8x32iCkBdhVSxMCTD0x+Q3LxDjAUW34OQXR3kUcfLea5aWl3ehpOa9igzEJ4YarPDaXPAzD3Q/SDfmsgeqUNn4mKxknqAQ6afZZI45D2wCsGoO6vzUDsIfqM8lWgyslAvmo/MnYIy/q6MWWxdJ7VSaaBKFr3/BGiMzIfw5+Q== X-OriginatorOrg: axentia.se X-MS-Exchange-CrossTenant-OriginalArrivalTime: 25 Nov 2016 16:19:45.9478 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM5PR0201MB2305 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 5782 Lines: 130 On 2016-11-25 14:39, Linus Walleij wrote: > On Fri, Nov 25, 2016 at 10:24 AM, Peter Rosin wrote: >> [Me] >>> struct device *gpiod_get_backing_device(struct gpio_desc *d); >>> >>> Is simple but is it really what you want? >> >> Well, my first attempt was to simply have a property in the >> devicetree stating that the mux was controlled from the same >> i2c bus it was muxing, but that was shot down because it >> should be possible to deduce this from the implementation (or >> something of that meaning, it was a while ago), which to me >> meant examining the "struct device"-tree. > > The problem goes into any subsystem providing resources for > a mux in this case, generally for example it is not OK for a > device to runtime suspend or shut down its regulator or turn off > its clock if it is acting as a mux. GPIO and pin control just happens > to be two resource in this specific case. Just to be clear, we are only talking of muxers used to mux an i2c-bus. But if some other popular bus is muxed the problems would probably be similar. If there is any action (that is not aware of the mux) on the muxed i2c-bus as the result of a i2c-mux-foo driver requesting a change to update the mux state, this will deadlock. Unless of course the mux is operated with the more relaxed locking (mux-locked instead of parent-locked). So yes, if some multi-function chip provides a gpio pin to some i2c-mux, and if this chip for some reason triggers some strange action when a gpio change is requested, and this action in turn triggers a transfer on the muxed i2c-bus, it will not work as intended (it will deadlock). I.e., there are all kinds of ways to defeat the current check to determine if i2c-mux-gpio and i2c-mux-pinctrl need relaxed locking. But none or them worked in this setting before I introduced the more relaxed mux-locked mode either, so I do not feel all that bad about it. And the checks can of course be improved if needed. >> For the gpio_desc it is easy. However, it is worse for the >> pinctrl case. > > It is annoying to do this in a sense, because it starts to kill > the abstraction we have created exactly in order to avoid > consumers having to worry much about their providers > internals. No we are opening the can and letting the stuff > out all over the place. Sorry about that. If it matters I'd be just as happy to have the devicetree author declare the situation explicitly for the i2c-mux driver, and I didn't really try to argue for that. Maybe it can be argued that the needed little piece of info isn't really all that specific to the linux implementation? Let me try: -----------8<----------- It is unreasonable to require that the i2c-mux code can determine if the devices needed to operate the mux needs to use the i2c-bus that is muxed. This requires domain knowledge of the whole system, and fingers everywhere. There should not be a design restriction on the system such that this question must have answer. Assuming everybody agrees with the above, the question becomes: Is it required that the i2c-mux code knows if any devices needed to operate the mux needs to use the i2c-bus that is muxed? I say yes. Case one: Normal iomem gpios directly from some SOC are used to mux an i2c-bus. If the i2c-bus is not locked as these gpios are updated, you might see half a transfer on one i2c child channel, and the other half on some other channel. Or worse. This might wreak havoc among the client devices. I.e. the i2c-mux must in this case lock the i2c-bus during the gpio update to make sure nothing bad hits the clients devices. Case two: A gpio update might need to use the muxed i2c-bus. The simplest case is if the io-expander used to operate an i2c-mux sits on the same i2c-bus that it is muxing, but it might be a lot more complex with a chain of dependencies ending up causing an i2c transfer (also, the client devices are known to handle broken crap on the i2c-bus and are not affected by a little bit of garbage). I.e. the i2c-mux must in this case make sure to not lock the i2c-bus during the gpio update. In other words, without a full view of the system, it is not possible to know if the i2c-bus should or should not be locked when updating the gpios used to operate a mux on the i2c-bus. -----------8<----------- I can take the above argument to the dt list and perhaps win them over. But that doesn't mean that we can simply remove the code, since doing so would regress anything depending on the current behavior of (at least sometimes) automatically finding the i2c dependency. But maybe the users are few and able to add a dt property in case it's needed? And I like code that works without configuration, so I would prefer it to remain and continue to discover the easy case. > Have you looked into the discussion about device dependencies > in general? Isn't this problem mappable as a subset of that? Haven't seen it before. My understanding of the driver model is not the best, and the docs are behind which makes it hard to know what to believe. The discussions generally fly a bit over my head, I guess I simply need to dig into the code a bit more... > This was discussed at length at the last kernel summit: > https://lwn.net/Articles/705852/ > > See especially Rafael's commit > 9ed9895370aedd6032af2a9181c62c394d08223b > to driver core in linux-next This looks like it could be useful; given a gpio, look up its device, then do a deep search of the supplier list and look for any device sitting on the muxed i2c-bus. But of course consumers might also get a notifier and react. I think it's next to impossible to automatically cover all cases... An that still requires the i2c-mux driver to lookup the backing device of gpios (or device_s_ for pinctrl-states). Cheers, Peter