From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1764352AbdAKQyX (ORCPT ); Wed, 11 Jan 2017 11:54:23 -0500 Received: from mout.kundenserver.de ([212.227.126.130]:51723 "EHLO mout.kundenserver.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751364AbdAKQyV (ORCPT ); Wed, 11 Jan 2017 11:54:21 -0500 From: Arnd Bergmann To: Benjamin Tissoires Cc: Andrew Duggan , Dmitry Torokhov , Christopher Heiny , Nick Dyer , linux-input@vger.kernel.org, linux-kernel@vger.kernel.org, Lyude Paul Subject: Re: [PATCH] Input: synaptics-rmi4 - make F03 a tristate symbol Date: Wed, 11 Jan 2017 17:54:11 +0100 Message-ID: <4430320.ODnESzmqU3@wuerfel> User-Agent: KMail/5.1.3 (Linux/4.4.0-34-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <20170111162828.GA7997@mail.corp.redhat.com> References: <20170110121718.2992211-1-arnd@arndb.de> <4257703.BL932J6KbN@wuerfel> <20170111162828.GA7997@mail.corp.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Provags-ID: V03:K0:TJKPOO+2dq3eRIA1ttxSWFKOA1KmWgvWBCRTOe2kwW7cmWXWPM5 yelKtNGR2PHlVRraecnTO7ihNtELrOJA1tr1PmUUOvQMakw7DAohH0Q8XHdtWp7IzP1Y9l5 zB1cHknSH7nNQ5hVVVvzvMrgwy5AtUUlwTREyAmp8IiZLzsRXZ4EDYAHs+WU/Q0K3VxF18L CTgYMp3nUJ3Xr4/nEOCbg== X-UI-Out-Filterresults: notjunk:1;V01:K0:vmPH0O69h88=:stwUD93s9O9UTyzctheo8d LzJDumiyrhNbeyeZfYiO/ybXzNoKP1o0PYfbse14ptB6YV0NYCrBdfGKZ/MBiWtb7uOT81aGF SQXTGM6Yz8gSNXT7u/Uo8tAFB95Qj7T/Ham9aDpY7cba27JjLCn9kmTO6wHbSMCvmeTHmaLcV IGf49xKG9HzW9udW3iNf2BpmHZRvb3fYMQJ4rxjoGvG4E/U8W/AdclEvWtlc9PqU9QW4dNmJv IlJDO/kenrPqdq5FPj6t47JufiQuK3zw6fAPWCBD6k9HWGOb1d4rcfZqaiD6yabAeSw6BGqIV Psnqd0ynx4EpjXXejis6Mu1+HyfZab+/IAcwt1J5DxNEJG6xpDL7wSSMORp9tGBWox3iObUHr ato57rM1ZrIJNHlNqZWZ7Sjsw6vRHgvZnmlWujIK+QAxtPBKk3hKXCEhLLioF0lklJ5z19YVp K/WHOwTZ1WxAjDjOsu+Cwyp1dbQpe4Cspj+PbHCZKcUZXUDfhmwTmKEvqjY+HM/0LAa0Selik ToT2eoMFHPhZYj5EuA4ZS31euEsIsv207Vso0mltFKxI48mvkgGGVAYenQljfKTgA4RgUD9Gd KaCVDNLfHQifD0qhv9qrkqq8nGQyJkRIumYRbMXvTozd/7luLsV1FlcQEMCx72c/KonhUUh6R zXA5yWdo+ZM6BDQNjkiUyeEaEU7fWeyVlhTHzjrnhL8IkZRm+6A057k9Bx0G0TGwKj3DS+1nd yLQfFEh7fdt0jNnP Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wednesday, January 11, 2017 5:28:28 PM CET Benjamin Tissoires wrote: > Yep, it was initially written that way, and IIRC there was some issues > depending on how the drivers were compiled. For example, if rmi4_core is > Y and some functions are m, you can't load the device initially, so you > send a -EPROBE_DEFER, but how can you be sure that the function will > ever be loaded? I'm not sure if I understand your problem correctly, but normally the way it's done is that the bus driver notifies user space that a new device has appeared on the bus, and udev looks for the right driver for the device, using a MODULE_DEVICE_TABLE list. Once the driver gets loaded, it binds to the device. > Given that we need to have all the functions loaded during probe, we > decided to switch to a monolithic rmi4_core driver that has everything > it needs inside. If everything is in one module, you can probably get rid of at least part of the bus abstraction as well and just call the functions directly. Looking through the driver some more, I also find the 'rmi_driver rmi_physical_driver' concept very odd, you seem to have a device on the bus that is actually just another representation of the parent device and that creates another set of devices for the functions. Either I misunderstand what this is for, or you have a candidate for cleanup there and once you remove it (by calling rmi_driver_probe() instead of rmi_register_transport_device() to oversimplify the idea), the actual probing for the function drivers becomes much easier to do right. Arnd